Seeking reflections on our tag library (as a framework)

[Don Brown <mr...@twdata.org>]

At Atlassian, every application seems to have picked a different web
framework and template engine to use.  As we are finally starting to
do some common UI work, I'm wondering if the Struts 2 tag library
framework is worth basing our tag library on.  Assume it wouldn't be
too hard to extract mostly as-is:
* Is the design solid?
* How limiting do you find it over native tags/macros in the
respective template engines?
* How useful is the theme system really? For example, properties that
are only used by some themes are confusing and error-prone.
* Any performance bottlenecks outside all the OGNL usage?
* Would Struts be interested in the result?

The benefits I see are:
* Support for Velocity, Freemarker, and JSP
* Overridable, customizable Themes
* Ability to plug in a new template engine
* Generated tld and docs

While I've worked a bit on the tags from a struts dev pov, I've
haven't used them much myself.  My gut feel is it would be worth it in
the short and long term, however I remember some discussion about
their design and value, so I'd like to revisit those concerns.

BTW, was digging around in the javatemplate stuff...very impressive!
It is cool to see simple prototype code turned into a full featured
library.  Any thoughts on how that sax-like design worked out?  Should
it have been a more DOM-like object model instead?

Don

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Seeking reflections on our tag library (as a framework)

[Antonio Petrelli <an...@gmail.com>]

2009/8/11 Musachy Barroso <mu...@gmail.com>:
> Like Eric said, one of the things that I dislike about the current
> tags is the inheritance of the attributes. Out tags for the tld
> generation have ways to hack around that problem, but it still smells.

I don't know how it is OT, but maybe it might interest you.
At Tiles I realized a pure Java "template" layer, mad only of "start",
"end" and "execute" methods (with different parameters) that
represent, respectively, the start, the end or the execution of a tag
(the execution usually means a tag with no body).
Around that I created three "tag" layers, for JSP, FreeMarker and Velocity.
This was possible essentially because in Tiles there is an abstraction
of the request (TilesRequestContext) that can represent a servlet
request, a JSP's PageContext, a FreeMarker Environment, etc.
My idea is that, in a near future, this mechanism can be extended to
tag generation, starting from the template, for different template
engines.

Reference:
http://tiles.apache.org/framework/tutorial/extension/template.html

Code:
http://svn.eu.apache.org/repos/asf/tiles/framework/trunk/tiles-template/
http://svn.eu.apache.org/repos/asf/tiles/framework/trunk/tiles-jsp/
http://svn.eu.apache.org/repos/asf/tiles/framework/trunk/tiles-velocity/
http://svn.eu.apache.org/repos/asf/tiles/framework/trunk/tiles-freemarker/

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Seeking reflections on our tag library (as a framework)

[Musachy Barroso <mu...@gmail.com>]

Like Eric said, one of the things that I dislike about the current
tags is the inheritance of the attributes. Out tags for the tld
generation have ways to hack around that problem, but it still smells.

About the java templates, I would have liked a DOM-like approach
better, but it is personal preference I guess. I always find SAX-like
less intuitive, and in this case, is not like we get any performance
improvement or anything, but it is not a big deal.

> * How useful is the theme system really? For example, properties that
are only used by some themes are confusing and error-prone.

I am not sold on the idea of themes, I think different tlds would work
better. I find those properties (common to all themes but used only in
some) very confusing

>* Would Struts be interested in the result?

Not sure what you mean.

musachy
-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Seeking reflections on our tag library (as a framework)

[Obinna <ob...@gmail.com>]

I've worked with the struts tags a bunch in extending them for application
specific purposes (injecting authorization controls to disable components),
developing custom themes, and in developing an ajax framework extending
these tags and though I am very happy with the tag library in general, there
is one unsettling design point that I keep coming across:

It seems intuitive to me that tags can/should be categorized into certain
'functional groups' and an inheritance hierarchy be used to consolidate
common functionality into abstract base tags (for example: Input,
Interactive, Container..) which concrete implementations inherit. Because
tags/models can be so verbose, there is a significant benefit here for code
reuse and maintenance.
The problem is that one tag/component may typically exhibit multiple
'functions' and given the lack of multiple-inheritance, the only way to
accomplish is this is using some sort of delegate pattern which quickly
becomes just as verbose.
The struts2 tags seem to take a mid-way approach in which they implement a
lot of 'standard' functionality in a few abstract base tags (see UIBean,
ListUIBean...) but don't really try to 'normalize' the functionality too
much. The problem with this is that you end up having a ton of attributes
for every tag, many of which are not really implemented or meaningful for a
particular tag (ex: requiredposition or ondblclick for the FormTag).

It's not the worst thing in the world, but it makes things a bit more
confusing than they need to be especially if you are extending the tags and
don't want to implement *all* the attributes provided.

I also really like the approach taken with the javatemplates template .
Something like this applied to the tags would allow a much more discreet
segmentation of tag functionality which could be then 'plugged in' to each
tag as required. It sort of seems like a paradigm for reusing multiple
concerns in java without multiple inheritance - which is what this would
need.

- Eric



Though I am also a big fan of the struts tags, there is one particlar thing
that has always troubled me when trying to extend them for

On Tue, Aug 11, 2009 at 5:51 PM, Wes Wannemacher <we...@wantii.com> wrote:

> Don,
>
> As you know, there are many aspects to the taglib that make it
> interesting. One big thing that you mention is the use of the tobago
> plugin to generate the TLDs and marking parameters as attributes with
> an annotation. I'm guessing this was done at some point to make the
> taglib more manageable, but I've used this facility to generate my own
> tags for apps... It is a much friendlier setup than linking against
> jsp-api directly and trying to build the tag from scratch.
>
> Personally, I don't use Freemarker for Velocity, so the fact that it
> works outside of JSP is nifty, but of no real use to me. Although, I
> have used freemarker to generate email messages, I don't find myself
> using any struts tags in there, I generally just populate the model
> and render the template...
>
> I will say that that the theming is what sells it for me. I like
> breaking down the UI using the struts themes and sitemesh. My JSPs are
> very slim, it's not uncommon to find pages that just look like this -
>
> <html>
> <title>blah</title>
> <body>
> <div id="pageHeader">stuff</div>
> <div id="pageForm">
> // struts form tags
> </div>
> </body>
> </html>
>
> Part of the reason is that I am terrible at UI design. If left up to
> me, sites that I work on would look like someone barfed up their
> alphabet soup. It's just my nature, I was a terrible dresser until my
> wife taught me the basics and I still struggle sometimes. The
> templating allows me to apply a consistent look and Yes, I customize
> it quite often. I'd imagine that there are other ways to get the same
> result, but the s2 tags are a good fit. The elements being glued to
> the server-side components (via OGNL, etc.) and worry very little
> about anything other than the java end of things. Then, I can work
> with people wise in the ways of art to make the sites/tools actually
> be appealing to look at.
>
> HTML is just too flexible and there are too many ways to get the same
> output, so I generally look for consistency and manageability. Then, I
> can just browse places like this - http://www.openwebdesign.org to
> find a template that I like. It's usually trivial to convert one of
> those into a sitemesh decorator. The templateability of the tags lets
> me make the small changes I want to make things fit into the
> site-template I choose.
>
> Another thing that is useful is the overall design. The available tags
> make sense for the way I work. I am not sure if it is because I've
> trained my brain to approach problems a certain way after using
> struts2 for so long, or if they are just that good. But, I use tags
> like s:if / s:else and s:iterator quite a bit. I like exposing things
> from the action and being able to get to them in a uniform manner in
> the UI. I use the form tags quite a bit as well, but the whole package
> just seems like it is exactly what I would want it to be. There are
> some tags I stay away from though because I don't usually find any use
> for them -  s:optiontransferselect and s:action... I can't say that
> I've ever used them and I probably wouldn't. For the situations where
> I have to manage a set of lists I would rather use AJAX than a really
> complicated form tag.
>
> On Tue, Aug 11, 2009 at 10:19 AM, Don Brown<mr...@twdata.org> wrote:
> > At Atlassian, every application seems to have picked a different web
> > framework and template engine to use.  As we are finally starting to
> > do some common UI work, I'm wondering if the Struts 2 tag library
> > framework is worth basing our tag library on.  Assume it wouldn't be
> > too hard to extract mostly as-is:
> > * Is the design solid?
> > * How limiting do you find it over native tags/macros in the
> > respective template engines?
> > * How useful is the theme system really? For example, properties that
> > are only used by some themes are confusing and error-prone.
> > * Any performance bottlenecks outside all the OGNL usage?
> > * Would Struts be interested in the result?
> >
> > The benefits I see are:
> > * Support for Velocity, Freemarker, and JSP
> > * Overridable, customizable Themes
> > * Ability to plug in a new template engine
> > * Generated tld and docs
> >
> > While I've worked a bit on the tags from a struts dev pov, I've
> > haven't used them much myself.  My gut feel is it would be worth it in
> > the short and long term, however I remember some discussion about
> > their design and value, so I'd like to revisit those concerns.
> >
> > BTW, was digging around in the javatemplate stuff...very impressive!
> > It is cool to see simple prototype code turned into a full featured
> > library.  Any thoughts on how that sax-like design worked out?  Should
> > it have been a more DOM-like object model instead?
> >
> > Don
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Seeking reflections on our tag library (as a framework)

[Wes Wannemacher <we...@wantii.com>]

Don,

As you know, there are many aspects to the taglib that make it
interesting. One big thing that you mention is the use of the tobago
plugin to generate the TLDs and marking parameters as attributes with
an annotation. I'm guessing this was done at some point to make the
taglib more manageable, but I've used this facility to generate my own
tags for apps... It is a much friendlier setup than linking against
jsp-api directly and trying to build the tag from scratch.

Personally, I don't use Freemarker for Velocity, so the fact that it
works outside of JSP is nifty, but of no real use to me. Although, I
have used freemarker to generate email messages, I don't find myself
using any struts tags in there, I generally just populate the model
and render the template...

I will say that that the theming is what sells it for me. I like
breaking down the UI using the struts themes and sitemesh. My JSPs are
very slim, it's not uncommon to find pages that just look like this -

<html>
<title>blah</title>
<body>
<div id="pageHeader">stuff</div>
<div id="pageForm">
// struts form tags
</div>
</body>
</html>

Part of the reason is that I am terrible at UI design. If left up to
me, sites that I work on would look like someone barfed up their
alphabet soup. It's just my nature, I was a terrible dresser until my
wife taught me the basics and I still struggle sometimes. The
templating allows me to apply a consistent look and Yes, I customize
it quite often. I'd imagine that there are other ways to get the same
result, but the s2 tags are a good fit. The elements being glued to
the server-side components (via OGNL, etc.) and worry very little
about anything other than the java end of things. Then, I can work
with people wise in the ways of art to make the sites/tools actually
be appealing to look at.

HTML is just too flexible and there are too many ways to get the same
output, so I generally look for consistency and manageability. Then, I
can just browse places like this - http://www.openwebdesign.org to
find a template that I like. It's usually trivial to convert one of
those into a sitemesh decorator. The templateability of the tags lets
me make the small changes I want to make things fit into the
site-template I choose.

Another thing that is useful is the overall design. The available tags
make sense for the way I work. I am not sure if it is because I've
trained my brain to approach problems a certain way after using
struts2 for so long, or if they are just that good. But, I use tags
like s:if / s:else and s:iterator quite a bit. I like exposing things
from the action and being able to get to them in a uniform manner in
the UI. I use the form tags quite a bit as well, but the whole package
just seems like it is exactly what I would want it to be. There are
some tags I stay away from though because I don't usually find any use
for them -  s:optiontransferselect and s:action... I can't say that
I've ever used them and I probably wouldn't. For the situations where
I have to manage a set of lists I would rather use AJAX than a really
complicated form tag.

On Tue, Aug 11, 2009 at 10:19 AM, Don Brown<mr...@twdata.org> wrote:
> At Atlassian, every application seems to have picked a different web
> framework and template engine to use.  As we are finally starting to
> do some common UI work, I'm wondering if the Struts 2 tag library
> framework is worth basing our tag library on.  Assume it wouldn't be
> too hard to extract mostly as-is:
> * Is the design solid?
> * How limiting do you find it over native tags/macros in the
> respective template engines?
> * How useful is the theme system really? For example, properties that
> are only used by some themes are confusing and error-prone.
> * Any performance bottlenecks outside all the OGNL usage?
> * Would Struts be interested in the result?
>
> The benefits I see are:
> * Support for Velocity, Freemarker, and JSP
> * Overridable, customizable Themes
> * Ability to plug in a new template engine
> * Generated tld and docs
>
> While I've worked a bit on the tags from a struts dev pov, I've
> haven't used them much myself.  My gut feel is it would be worth it in
> the short and long term, however I remember some discussion about
> their design and value, so I'd like to revisit those concerns.
>
> BTW, was digging around in the javatemplate stuff...very impressive!
> It is cool to see simple prototype code turned into a full featured
> library.  Any thoughts on how that sax-like design worked out?  Should
> it have been a more DOM-like object model instead?
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>



-- 
Wes Wannemacher

Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Seeking reflections on our tag library (as a framework)

[Jeromy Evans <je...@blueskyminds.com.au>]

Hi Don,

My experience with the Struts2 tags has been fairly negative, mainly  
due to the UIBean base class. It's a fragile base class scenario in  
which you must extend UIBean if you want the benefit of the  
TemplateEngineManager, but UIBean contains a lot of crud that isn't  
applicable to its subclasses.

eg.
1. UIBean includes a property for every html attribute and tooltips  
etc.  When these aren't applicable to subclasses they have to be  
overridden and/or removed from the TLD (manually)
2. UIBean is tightly coupled to the TemplateEngineManager.  It seems  
you can't create tags that utilise Struts2's template/theme feature  
unless you subclass UIBean
3. UIBean is tightly coupled to the OGNL expressions (a parent class  
performs the expression evaluation)

There's also a lot of boilerplate code required in the current  
implementation (the Component impl, the Tag impl, the Velocity  
Directive and the FreeMarker TagModel).

Therefore I would say the design is not solid.  It's a reasonable  
basis though. When I last looked, I thought the TemplateEngineManager  
could be refactored to accept an interface to something that has  
properties (the tag and context) and can resolve expressions rather  
than invoking methods directly in UIBean to do this. As I dug deeper  
it got too hard.

Additionally the theme system is not solid due to frequently discussed  
issues with ${parameters.theme} within nested templates.  Hard-coding  
parent theme names within templates and duplication of templates for  
every new theme is necessary (theme inheritance doesn't work as one  
would expect).  There's no easy fix to that.

cheers,
Jeromy Evans

On 12/08/2009, at 12:19 AM, Don Brown wrote:

> At Atlassian, every application seems to have picked a different web
> framework and template engine to use.  As we are finally starting to
> do some common UI work, I'm wondering if the Struts 2 tag library
> framework is worth basing our tag library on.  Assume it wouldn't be
> too hard to extract mostly as-is:
> * Is the design solid?
> * How limiting do you find it over native tags/macros in the
> respective template engines?
> * How useful is the theme system really? For example, properties that
> are only used by some themes are confusing and error-prone.
> * Any performance bottlenecks outside all the OGNL usage?
> * Would Struts be interested in the result?
>
> The benefits I see are:
> * Support for Velocity, Freemarker, and JSP
> * Overridable, customizable Themes
> * Ability to plug in a new template engine
> * Generated tld and docs
>
> While I've worked a bit on the tags from a struts dev pov, I've
> haven't used them much myself.  My gut feel is it would be worth it in
> the short and long term, however I remember some discussion about
> their design and value, so I'd like to revisit those concerns.
>
> BTW, was digging around in the javatemplate stuff...very impressive!
> It is cool to see simple prototype code turned into a full featured
> library.  Any thoughts on how that sax-like design worked out?  Should
> it have been a more DOM-like object model instead?
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org