>> - tags are much faster then templates
>
> Can I ask how this is? You generate a TagLib from the GSP - but the GSP still gets executed when you invoke the "GSP tag" right?
>
> The body of the GSP Tag can call other taglibs can't it, so you have all the same overheads as a normal GSP pretty much?
When rendering a template, a page context needs to be constructed. This is not the case when calling a tag.
In my current project, we have about 50 UI components that where first build using a tag + template. Since most tags call other tags that call other tags... we got hundreds of templates rendered per page making everything slow. Migrating to gsp tags fixed the performance issue.
>
>> - tags come with an API, docs and code completion
>
> There is no difference here to a tag that calls g:render.
When I type "<c:box" , Intellij already adds the required attributes and has completion for the optional ones. When I type "<g:render", it doesn't have a clue about what's in the model.
Which would you prefer:
<c:box titleCode="my.title">...</c:box>
or
<g:render template="box" model="${titleCode: 'my.title}">...</g:template>
I guess this is the reason why grails has both tags and templates :)
>
>> - gsp tags are placed in the taglib dir where they belong, not in the views
>> dir
>
> Again this is a non-issue IMO. Its clear what a grails-app/views/_tags folder would be for.
You can easily navigate from a tag to its corresponding template, but not back. With more then 50 components this is not exactly convenient :(
>
>> - using g:render, you need to define 2 things: the template and the tag that
>> renders it
>>
>
> Yes, and that works within established mechanisms very well.
>
> There is just one way to write tags. That has value.
You still have to chose: will I inline my markup or put it in a separate template?
>
>>
>>> 2) Having all such code coming out of a non-generated TagLib you write
>>> gives better visibility - for docs, IDEs etc
>>>
>> Currently I already get navigation, syntax coloring and code completion both
>> when writing the tags and when using them. But most important, typical UI
>> components that contain more markup then logic, are far more easier to write
>> and to read in a gsp
>>
>
> How do you get that completion? Surely it is only possible in an IDE after your generated sources have been compiled by the IDE?
correct
>> Just lik JSP and JSF have two ways of defining tags; in java or in
>> JSP/facelet. The ratio logic/markup determines the choice
>>
>
> I would never suggest JSP or JSF as a sound model for concepts :)
>
> Just because they do something, it does not make it good.
Agree, but being able to create a reusable component by merely copying part of a page is definitely a good thing. The only feature I really miss after switching from JSF :)
>> Except for the above reasons, there is also marketing value: when my
>> colleagues tell about how easy you can create tags in JSP/JSF from a page
>> snippet, I just want to reply /grails can do that/ :)
>
>
> It can:
>
> class MyTagLib {
> def myTag = { attrs ->
> out << g.render(template:'/views/_tags/myTag', model:[attrs:attrs])
> }
> }
Done this, but unfortunately it is:
a) not performant
b) a maintenance nightmare in larger projects because you constantly need to keep 2 pieces of code in sync for one component
> Also note that type safety and checking of attribute values etc is best done in real TagLib code. Otherwise you are doing a lot of Groovy code in a GSP which is bad.
I agree that too much code in a gsp is not good, but on the other hand too much markup in code is even worse: my IDE has good support for code in gsp's, but it doesn't tell me that I forgot to close a html tag inside a concatenation of String literals, nor does it show nesting etc. :(
> I still vote -1, this should remain in a plugin. If more hooks are needed to help it integrate better, add the hooks, but IMO don't add this feature to core.
Besides a few hooks, the impact and risks of this feature are very small, so why not add it since it is generally useful in IMO
Grtz,
Ivo
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Locked
