tag in v1.0

[Pierre Métras <ge...@sympatico.ca>]

Hi,

Wouldn't it be interesting to have a tag to set an attribute value?

I see an immediate application to create conditional includes...

For instance, define
<bean:attribute name="com.acme.pageName" value="home" />
in your home page

and then
<logic:present name="com.acme.pageName" />
    <logic:equals name="com.acme.pageName" value="home" />
        <bean:include id="menu" name="/frontMenu.inc" />
    </logic:equals>
</logic:present>
to have a special menu on that page.

Of course, you can write it with a one-line java, but it would provide a
symetrical design with all the getter tags.
If needed, I can write such a tag tomorrow.

Pierre Métras

Re: tag in v1.0

[Pierre Métras <ge...@sympatico.ca>]

> Um, ...
>
> They didn't disappear -- they just moved :-).  Check out <logic:iterate>.
>
> The enumerate tag did disappear, however, since the community was OK with
> migrating to Java2.

Oups!!!

Pierre Métras

Re: tag in v1.0

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Pierre Métras wrote:

> Look at the iterating tags: they disappeared from version 1.0. I can think
> the reason is that control structures are more naturally expressed using
> Java code.

Um, ...

They didn't disappear -- they just moved :-).  Check out <logic:iterate>.

The enumerate tag did disappear, however, since the community was OK with
migrating to Java2.

>
> Pierre Métras

Craig

Re: tag in v1.0

[Pierre Métras <ge...@sympatico.ca>]

> Taylor Cowan wrote:
>
> > You should have set functionality if there is get functionality
(BeanUtils
> > as well which only does the get part), but I hope some of you are
careful
> > about over-tagism.  I agree that less Java in the JSP page is better,
but
> > the "J" in JSP does stand for Java.  If Java is so bad and difficult
then
> > why do we use it?  On one hand we're told, "look, you can inline Java,
> > great! lets' call it JSP".  Then we are told "Java in the JSP page is
bad,
> > use tags".  It should be TSP if that's the gospel.

Just to give the context of my request.
I don't think that custom tags are the solution to all the problems for Web
application development, neither JSP is. But Struts offers a collection of
minimalist but practical tags, to implement most usefull functions found in
application development. It's true, you can code all these functions with
Java, and performance will be better. But some people feel easier using
tags, other prefer including Java code. The same remark apply for tools:
some support JSP, other tags...

Look at the iterating tags: they disappeared from version 1.0. I can think
the reason is that control structures are more naturally expressed using
Java code.
But if we consider the JSP page as the View component of the application,
it's more natural to have tags to display information than to change it.

The present struts-bean tag library only provides getting features. I
thought that a complementary tag that would allow to set an attribute is
nice to have, at less for natural symmetry, though not following the design
view.

Pierre Métras

Re: tag in v1.0

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Taylor Cowan wrote:

> You should have set functionality if there is get functionality (BeanUtils
> as well which only does the get part), but I hope some of you are careful
> about over-tagism.  I agree that less Java in the JSP page is better, but
> the "J" in JSP does stand for Java.  If Java is so bad and difficult then
> why do we use it?  On one hand we're told, "look, you can inline Java,
> great! lets' call it JSP".  Then we are told "Java in the JSP page is bad,
> use tags".  It should be TSP if that's the gospel.
>

I think one of the key issues will be what tools the developer is using to
create the pages.

If you are an old Emacs hacker like me :-), you tend to prefer minimum
keystrokes and concise constructs, because my fingers have to type them all in.
However, if you're using a development tool, especially one that knows how to
deal with custom tags, the issues of verbosity or even syntax become totally
irrelevant (I'm continually amazed at how many web page designers don't know
what an HTML tag looks like because all they know is the tools they are using).

We're really early in the lifecycle of tools support for custom tags.  However,
once that story becomes more complete you will see IDEs that know how to
configure custom tags with popup windows (just like you can tweak the properties
of an HTML table in most web design tools today), and see the results live.

I would submit, however, that a tool can be taught to do this with custom tags,
but it would be quite difficult to do this in a useful way for general
scriptlets.

>
> The example you gave could be shortened considerably with Java.  I'm just
> not convinced that learning obscure logic oriented tags is any harder that
> just learning Java.

The end game, of course, is that you don't have to "learn" any more about custom
tags than you do about a <table>.  You need to know what it does, not how it is
coded.  From that perspective, consider custom tags to be plug-in components to
your favorite IDE.

>  I also believe that some of the strut's tag
> functionality will be duplicated by the Standard Tag Library.  The message
> tags, form tags, and tags directly related to the Struts framework are
> valid.  These logic tags are useful, but I'm just suggesting someone take a
> look and make sure each tag really needs to be there.  At the very least
> consider what is coming in the Standard Tag Library and assume people will
> gravitate to that standard.

You can count on Struts having an influence on (and being influenced by) the
standard tag library effort :-).  I'm going to be involved in the JSR-052 expert
group as this evolves, and communicate regularly with the spec lead for it
(Eduardo Pelegri-Llopart, who is also the spec lead for JSP 1.2).

>
>
> Taylor
>

Craig McClanahan

Re: tag in v1.0

[Taylor Cowan <ta...@bondisoftware.com>]

You should have set functionality if there is get functionality (BeanUtils
as well which only does the get part), but I hope some of you are careful
about over-tagism.  I agree that less Java in the JSP page is better, but
the "J" in JSP does stand for Java.  If Java is so bad and difficult then
why do we use it?  On one hand we're told, "look, you can inline Java,
great! lets' call it JSP".  Then we are told "Java in the JSP page is bad,
use tags".  It should be TSP if that's the gospel.

The example you gave could be shortened considerably with Java.  I'm just
not convinced that learning obscure logic oriented tags is any harder that
just learning Java.  I also believe that some of the strut's tag
functionality will be duplicated by the Standard Tag Library.  The message
tags, form tags, and tags directly related to the Struts framework are
valid.  These logic tags are useful, but I'm just suggesting someone take a
look and make sure each tag really needs to be there.  At the very least
consider what is coming in the Standard Tag Library and assume people will
gravitate to that standard.

Taylor


----- Original Message -----
From: "Pierre Métras" <ge...@sympatico.ca>
To: <st...@jakarta.apache.org>
Sent: Tuesday, November 21, 2000 8:43 PM
Subject: <bean:attribute> tag in v1.0


> Hi,
>
> Wouldn't it be interesting to have a tag to set an attribute value?
>
> I see an immediate application to create conditional includes...
>
> For instance, define
> <bean:attribute name="com.acme.pageName" value="home" />
> in your home page
>
> and then
> <logic:present name="com.acme.pageName" />
>     <logic:equals name="com.acme.pageName" value="home" />
>         <bean:include id="menu" name="/frontMenu.inc" />
>     </logic:equals>
> </logic:present>
> to have a special menu on that page.
>
> Of course, you can write it with a one-line java, but it would provide a
> symetrical design with all the getter tags.
> If needed, I can write such a tag tomorrow.
>
> Pierre Métras
>

Re: tag in v1.0

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Pierre Métras wrote:

> > How about adding a value attribute on <bean:define>?  That way, you would
> say
> >
> >     <bean:define id="com.acme.fileName" value="homePage"/>
> >
> > for the above case.
>
> I have dreamt of it.
>
> But I'm always suspicious with Swiss army knife solutions...

There is definitely an inherent balancing act in making a few super-powerful
things or lots of single-purpose things.  Most recently in Struts (as is
probably obvious if you are following the 1.0 developments ;-), I have tended
towards the "single tag per basic functionality" approach, and supported
variations by allowing different combinations of attributes.

For example, the <bean:define> tag can do a bunch of different things:
* Make an attribute that references the same object as some
  other existing attribute (id and name)
* Looks up a bean property and make it a new attribute (id, name,
  and property)
* The "property" in the previous case can actually be nested and/or
  indexed
* You can optionally set the Java class of the created interface, or
  accept the default (java.lang.Object)

So, the proposal is to add one more variation on the same theme -- define a new
attribute based on a literal string (or on a runtime expression), without the
limitation of <jsp:useBean> that you pointed out.

Doing single-purpose tags for all the possible combinations would be something
on the order of 10-20 variations.  The fact that they all do basically the same
thing ("define a new bean in some scope") would get hidden in the mass of
options.


> Will it manage
> null values in rtexprvalues?

The exact same issue comes up already if a property getter returns null.

I can't recall precisely where, but I think the specs forbid null attributes.
(If they were allowed, what does it mean if request.getAttribute() returns null
-- the value was there and null, or the value was not there?).

Also, any servlet container that uses java.util.Hashtable to store request and
session attributes isn't going to be able to deal with nulls anyway.

> And in that case "name" is no more mandatory
> else you can't use the tag two times in the same page: scripting variable
> redefined...

In <bean:define>, just as in <jsp:useBean>, it is the "id" that must be unique,
not "name".  You can use the same "name" value multiple times with no
difficulty, because it is only used to look up existing beans, not create new
ones.

>
> And later we would suggest <bean:define name="fileName" value="homePage" />
> in replacement of <jsp:useBean...> for JSP1.3;-)
>

Don't smile too much -- something like this sort of functionality would make a
lot of sense in the "Standard Tag Library".  A development effort called JSR-052
is just getting activated under the Java Community Process to establish a set of
standard tags that all JSP containers are required to implement.

Among the many roles that Struts plays, being a testbed for ideas like this is
interesting.

>
> Well, the night is a good advisor (direct French translation;-)
>

Bon soir :-)

>
> Pierre Métras

Craig

Re: tag in v1.0

[Pierre Métras <ge...@sympatico.ca>]

> How about adding a value attribute on <bean:define>?  That way, you would
say
>
>     <bean:define id="com.acme.fileName" value="homePage"/>
>
> for the above case.

I have dreamt of it.

But I'm always suspicious with Swiss army knife solutions... Will it manage
null values in rtexprvalues? And in that case "name" is no more mandatory
else you can't use the tag two times in the same page: scripting variable
redefined...
And later we would suggest <bean:define name="fileName" value="homePage" />
in replacement of <jsp:useBean...> for JSP1.3;-)

Well, the night is a good advisor (direct French translation;-)

Pierre Métras

Re: tag in v1.0

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Pierre Métras wrote:

> Hi Craig,
>
> I wrote:
> > > Wouldn't it be interesting to have a tag to set an attribute value?
>
> You answered:
> > Is there something you need that <jsp:useBean> cannot do?
>
> Can I write <jsp:useBean id="com.acme.myBean"...> to access/create an
> attribute with a dotted path?
>

Nope -- that's a restriction in the JSP spec because it uses the "id" attribute
both as the key for bean lookup *and* for the local variable name.  I submitted
an enhancement request for JSP 1.2 to let you use different values for these two
purposes, but it didn't make it into the current draft :-(.

>
> I just wanted a simpler way to mimic:
> <%
>     session.setAttribute("com.acme.fileName", "homePage");
> %>
>
> without having to rely on scripting code.
>

How about adding a value attribute on <bean:define>?  That way, you would say

    <bean:define id="com.acme.fileName" value="homePage"/>

for the above case.


>

>
> Pierre Métras

Craig

Re: tag in v1.0

[Pierre Métras <ge...@sympatico.ca>]

Hi Craig,

I wrote:
> > Wouldn't it be interesting to have a tag to set an attribute value?

You answered:
> Is there something you need that <jsp:useBean> cannot do?

Can I write <jsp:useBean id="com.acme.myBean"...> to access/create an
attribute with a dotted path?

I just wanted a simpler way to mimic:
<%
    session.setAttribute("com.acme.fileName", "homePage");
%>

without having to rely on scripting code.

Pierre Métras

Re: tag in v1.0

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Pierre Métras wrote:

> Hi,
>
> Wouldn't it be interesting to have a tag to set an attribute value?
>
> I see an immediate application to create conditional includes...
>
> For instance, define
> <bean:attribute name="com.acme.pageName" value="home" />
> in your home page
>
> and then
> <logic:present name="com.acme.pageName" />
>     <logic:equals name="com.acme.pageName" value="home" />
>         <bean:include id="menu" name="/frontMenu.inc" />
>     </logic:equals>
> </logic:present>
> to have a special menu on that page.
>
> Of course, you can write it with a one-line java, but it would provide a
> symetrical design with all the getter tags.
> If needed, I can write such a tag tomorrow.
>

Is there something you need that <jsp:useBean> cannot do?

>
> Pierre Métras

Craig