webwork-user — WebWork users mailing list

Re: [Webwork-user] Documentation?

[Maurice C . P. <Ma...@Vi...>]

* Rickard Öberg (ri...@jb...) wrote:
> Hi!
> 
> I've been thinking about how to do docs best. I'm leaning towards using
> XML and DocBook. Once you got it running it is pretty nice, and you get
> a nice looking HTML output. And AFAIK it is possible to get it to PDF
> too.

And a handfull of other formats as well.  Plain text, PostScript, SGML, etc...

> 
> The only problem I see with it is that the docbook and Xalan parsers
> needed to convert XML to HTML are *HUGE*. This is no problem if you're
> developing continuously since you'd get them once and be done with it,
> but the CVS tar ball will be quite a lot larger.

Yes, but I wouldn't loose too much sleep over 2MB.

> 
> Any thoughts on this?

The exolab uses an ant task that not only builds their docs, but builds their website from XML as well.  As far as XLST translations are concerned, it's fairly quick.

Docbook has a learning curve, but is something of a standard in the Linux community.IIRC, the XML Apache community uses a simplified version of Docbook for it's docs.  It may be something to consider.

I'd like to see some kind of XML format is good, just because you can process it into HTML, PDF, etc...

Later,

Maurice

[Webwork-user] Documentation?

[Rickard <ri...@jb...>]

Hi!

I've been thinking about how to do docs best. I'm leaning towards using
XML and DocBook. Once you got it running it is pretty nice, and you get
a nice looking HTML output. And AFAIK it is possible to get it to PDF
too.

The only problem I see with it is that the docbook and Xalan parsers
needed to convert XML to HTML are *HUGE*. This is no problem if you're
developing continuously since you'd get them once and be done with it,
but the CVS tar ball will be quite a lot larger.

Any thoughts on this?

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] WebWork 0.7 updated in CVS

[Rickard <ri...@jb...>]

WebWork 0.7 status

I have fixed the bug that made the form test crash (equals tag didn't
handle null values well). So now everything works.

SourceForge still don't have the file release working. For now, if you
don't want to use CVS I have put a zip here:
ftp://download.sourceforge.net/incoming/webwork-0.7.zip

Starting with this release the name of the zip is in lower case. When
you unzip it it will create a base directory called "webwork-0.7" so
there is no need to make one manually. This seems to be common practice,
so I thought WebWork should do this too.

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] Error in build.xml

[Maurice C . P. <Ma...@Vi...>]

Rickard,

It looks like your out for the day, so I went ahead and committed the change to CVS.

Maurice

* Maurice C . Parker (Ma...@vi...) wrote:
> Rickard,
> 
> There is an oops in the build.xml file.  The jaxp.jar is not being found because of a missing semi-colon before it's definition in the classpath.
> 
> Maurice
> _______________________________________________
> Webwork-user mailing list
> Web...@li...
> http://lists.sourceforge.net/mailman/listinfo/webwork-user

Re: [Webwork-user] Lots of cool updates

[Andrius J. <an...@li...>]

hi,

is it just me or the FormTestForm.action doesn't find some include? I get
something like this:

Included servlet error: 500
Location: /webwork/FormTestForm.action
Error Location: /webwork/template/standard/select.jsp
Internal Servlet Error:
javax.servlet.ServletException: Include failed:null
 at
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImp
l.java:453)
[...]
root cause of this:
javax.servlet.jsp.JspTagException: Include failed:null
	at webwork.taglib.IncludeTag.doEndTag(IncludeTag.java:97)
[...]

regards,
--andrius
----- Original Message -----
From: "Rickard Öberg" <ri...@jb...>
To: <web...@li...>
Sent: Wednesday, December 13, 2000 8:03 PM
Subject: [Webwork-user] Lots of cool updates


: Hey
:
: SourceForge file release is still down, but I have now added loads of
: cool stuff to CVS.
:
: Support for ":foo" type names is in, which allow you to scope names to
: the root of the value stack.
:
: The Timer bean, which allow you to check how long time a page takes, has
: been moved to the new package webwork.util. webwork.util will contain
: beans that are so useful that they should always be available.
:
: A new Counter bean has been added to webwork.util. It counts. 1, 2, 3,
: 4. Or 0, 5, 10, 15. Or 5, 6, 7, 8, 6, 7, 8, etc. And it can be used as
: an iterator:
: <webwork:bean name="webwork.util.Counter">
:   <webwork:param name="first" value="1"/>
:   <webwork:param name="last" value="5"/>
:   <webwork:param name="interval" value="2"/>
:
: <webwork:iterator>
:   <webwork:property/> <!-- Print 1,3,5 -->
: </webwork:iterator>
:
: A new DateFormatter bean has been added to webwork.util. It can format
: dates. Like this:
: <webwork:bean name="webwork.util.DateFormatter">
:   <webwork:param name="parseFormat">d</webwork:param>
:   <webwork:param name="format">EEEEEE</webwork:param>
:
:   <webwork:param name="date" value="2"/>
:
:   <webwork:property name="formattedDate"/> <!-- Print "monday" -->
: </webwork:bean>
:
: The monthlist example has been completely reworked, and now showcases
: the above beans extensively. It now shows a calendar for the current
: year (i.e. twelve months instead of just one), and todays date is marked
: red.
:
: WARNING: this page uses A LOT of tags, and will take a long time to
: compile/load (takes up to 30 seconds on my Athlon/650Mhz/256Mb). This is
: hence a good test for the efficiency of the JSP compiler. Currently
: Tomcats JSP compiler is not very good since it doesn't reuse tags, so it
: will be slow. However, if you reload this page a couple of times the
: page time will go down. If I reload the page 5-6 times the total time
: for the last reload is 2 seconds instead of 30! (i.e. very important to
: preload pages for demos :-)
:
: The "equals" tag now converts the objects it compares to strings *if
: they are not of the same class*. For example, if you want to compare a
: java.lang.Long with the value 5 with the string "5" then the comparison
: will be true, since the Long will be converted to a string before
: checking. I think this will be more similar to what one expects than if
: a stricter comparison without conversion is done.
:
: That's all for this time :-) Let me know if you have any bug reports,
: comments, suggestions etc. regarding the above (or anything else WebWork
: related of course).
:
: regards,
:   Rickard
:
: --
: Rickard Öberg
:
: Email: ri...@jb...
: _______________________________________________
: Webwork-user mailing list
: Web...@li...
: http://lists.sourceforge.net/mailman/listinfo/webwork-user
:

Re: [Webwork-user] Lots of cool updates

[Andrius J. <an...@li...>]

hi,

: WARNING: this page uses A LOT of tags, and will take a long time to
: compile/load (takes up to 30 seconds on my Athlon/650Mhz/256Mb). This is
: hence a good test for the efficiency of the JSP compiler. Currently
: Tomcats JSP compiler is not very good since it doesn't reuse tags, so it
: will be slow. However, if you reload this page a couple of times the
: page time will go down. If I reload the page 5-6 times the total time
: for the last reload is 2 seconds instead of 30! (i.e. very important to
: preload pages for demos :-)

have you tried using jikes instead of javac for jsp compilation? on my
configuration, which is the same as yours, I get 1st load time of 20sec
instead of 30 :)
there is a commented out setting in tomcat 3.26 configuration file
conf/web.xml - this should save you some time if you aren't using it
already.
and does jetty support taglibs? maybe it with is faster with this gnujsp
stuff?

regards,
--andrius

[Webwork-user] Error in build.xml

[Maurice C . P. <Ma...@Vi...>]

Rickard,

There is an oops in the build.xml file.  The jaxp.jar is not being found because of a missing semi-colon before it's definition in the classpath.

Maurice

[Webwork-user] Lots of cool updates

[Rickard <ri...@jb...>]

Hey

SourceForge file release is still down, but I have now added loads of
cool stuff to CVS.

Support for ":foo" type names is in, which allow you to scope names to
the root of the value stack.

The Timer bean, which allow you to check how long time a page takes, has
been moved to the new package webwork.util. webwork.util will contain
beans that are so useful that they should always be available. 

A new Counter bean has been added to webwork.util. It counts. 1, 2, 3,
4. Or 0, 5, 10, 15. Or 5, 6, 7, 8, 6, 7, 8, etc. And it can be used as
an iterator:
<webwork:bean name="webwork.util.Counter">
  <webwork:param name="first" value="1"/>
  <webwork:param name="last" value="5"/>
  <webwork:param name="interval" value="2"/>

<webwork:iterator>
  <webwork:property/> <!-- Print 1,3,5 -->
</webwork:iterator>

A new DateFormatter bean has been added to webwork.util. It can format
dates. Like this:
<webwork:bean name="webwork.util.DateFormatter">
  <webwork:param name="parseFormat">d</webwork:param>
  <webwork:param name="format">EEEEEE</webwork:param>

  <webwork:param name="date" value="2"/>

  <webwork:property name="formattedDate"/> <!-- Print "monday" -->
</webwork:bean>

The monthlist example has been completely reworked, and now showcases
the above beans extensively. It now shows a calendar for the current
year (i.e. twelve months instead of just one), and todays date is marked
red. 

WARNING: this page uses A LOT of tags, and will take a long time to
compile/load (takes up to 30 seconds on my Athlon/650Mhz/256Mb). This is
hence a good test for the efficiency of the JSP compiler. Currently
Tomcats JSP compiler is not very good since it doesn't reuse tags, so it
will be slow. However, if you reload this page a couple of times the
page time will go down. If I reload the page 5-6 times the total time
for the last reload is 2 seconds instead of 30! (i.e. very important to
preload pages for demos :-)

The "equals" tag now converts the objects it compares to strings *if
they are not of the same class*. For example, if you want to compare a
java.lang.Long with the value 5 with the string "5" then the comparison
will be true, since the Long will be converted to a string before
checking. I think this will be more similar to what one expects than if
a stricter comparison without conversion is done.

That's all for this time :-) Let me know if you have any bug reports,
comments, suggestions etc. regarding the above (or anything else WebWork
related of course).

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] WebWork + XML = !

[Maurice C . P. <Ma...@Vi...>]

* Rickard Öberg (ri...@jb...) wrote:
> 
> So, what do you think? Is this good enough? It was a bit tricky to get
> this to work, but now it does. I'm just wondering if the above is too
> simplistic, or if it enough to use XML with WebWork.

I'm planning on doing an RSS implementation of this for VineyardEnterprise.com.  I'll send you the code when I get done and you can use it as a more complex example if you want.

Later,

Maurice

Re: [Webwork-user] Name collision (FIXED)

[Rickard <ri...@jb...>]

"Maurice C . Parker" wrote:
> * Rickard Öberg (ri...@jb...) wrote:
> > Hi!
> >
> > I could easily add :foo to get to the top. There would be no significant
> > performance penalty to do this.
> >
> Please, please, please do.  Even thought the ":" and ".." aren't very intuitive either, at least there is president for this syntax.  People can say, "Oh, it's just like a file system except I use a colon instead of a forward-slash."

Done. Or at least I have it done locally. Not sure if I've committed it
properly yet. I'm working on a revamped "month list test" and will
commit it for sure when that's done.

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] Name collision (FIXED)

[Maurice C . P. <Ma...@Vi...>]

* Rickard Öberg (ri...@jb...) wrote:
> Hi!
> 
> I could easily add :foo to get to the top. There would be no significant
> performance penalty to do this.
> 
Please, please, please do.  Even thought the ":" and ".." aren't very intuitive either, at least there is president for this syntax.  People can say, "Oh, it's just like a file system except I use a colon instead of a forward-slash."

Thanks!

Maurice

Re: [Webwork-user] WebWork optimizations

[Maurice C . P. <Ma...@Vi...>]

* Rickard Öberg (ri...@jb...) wrote:
> I have notified the Tomcat dev mailing list and hopefully this will be
> fixed, in which case you're going to see some performance enhancements
> for tags inside iterators. Since this is very common the total effect
> should be very good.

Thank you.  This should help my Jive performance.  Now to make sure my code is fast...  8-)

> 
> I have also changed the name resolution a bit so that $foo can mean
> either "take value of foo parameter" or "take value of foo attribute"
> (in that order). This means that in theory it should be possible to use
> <@ include> instead of <jsp:include> for generic controls. However,
> currently the controls contain JSP code that explicitly uses request
> parameters, so it doesn't work yet.
> 
> If the code in the controls is changed so that either request parameters
> or attributes can be used, then it will work well. This should improve
> performance even more. Come to think of it, is there any reason to use
> jsp:include at all? I.e. could we change the generic controls to
> *always* get request attributes? That'd work in that case. Any
> objections to this?
> 

I think that there are more benefits to using the include directive over the include tag than just performance.  For example you would now be able to nest controls inside of the Webwork tags.

<webwork:istrue name="extraQuestion">
	<@ include file="/template/standard/text.jsp @>
</webwork:istrue>

This isn't possible with the jsp tag because it tries to flush the buffer inside the custom Webwork tag, which is illegal.

If no one speaks up within the next few hours I will begin implementing this and hopefully have it committed this evening (in the USA, that is).

Later,

Maurice

[Webwork-user] XML + timer in CVS

[Rickard <ri...@jb...>]

Hi!

Alright, I have added the XML support and XML example to CVS. Check it
out and let me know if it is ok.

I have also added a simple timer bean that you can use to time your
pages. Very useful! I have added it to test.jsp to show how to use it.
Basically, it works like this.

Put this at the top of your page:
<webwork:bean name="webwork.test.Timer" id="timer"/>

Then do stuff, and when you want to know how many milliseconds have
elapsed since the beginning of the page you add:
<webwork:property name="timer@time"/>
This will print out the nr of milliseconds since the beginning, *or the
last time you printed it out*. Because, now you can do more stuff, and
the next time you print it out it will be the time elapsed since last
printout. If you want the total for the page you can use the property
"timer@total".

So, typically you will do this:
<webwork:bean name="webwork.test.Timer" id="timer"/>
... dostuff
<webwork:property name="timer@time"/>

... domorestuff
<webwork:property name="timer@time"/>

... doevenmorestuff
<webwork:property name="timer@time"/>

<webwork:property name="timer@total"/>

This will give you a nice breakup over what parts on your page take a
lot of time, and also the time taken to produce the whole page.

regards,
  Rickard

ps. Still trying to do a file release of this on SourceForge... lots of
other people have the same problem so at least it's not just me..

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] WebWork + XML = !

[Rickard <ri...@jb...>]

Hi!

I'm doing some XML+WebWork integration experiments. I have extended the
"iterator" and "property" tags to understand XML DOM.

Let me show you.

Example action:
public class PeopleList
   extends ActionSupport
{
   // Attributes ----------------------------------------------------
   static Node people;
   
   static
   {
      // This never changes, so we do it once only
      
      // We read the values from an XML file so that it is easy to
change
      try
      {
         InputStream resource =
AgeList.class.getResourceAsStream("people.xml");
         BufferedReader in = new BufferedReader(new
InputStreamReader(resource));
         
         DocumentBuilderFactory docBuilderFactory =
DocumentBuilderFactory.newInstance();
         DocumentBuilder docBuilder =
docBuilderFactory.newDocumentBuilder();
         people = docBuilder.parse(new
InputSource(in)).getDocumentElement();
      } catch (Exception e)
      {
         e.printStackTrace(System.err);
         System.err.println("Could not read list of people");
      }
   }
   
   // Public --------------------------------------------------------
   public Node getPeople()
   {
      return people;
   }
}

Example XML:
<people>
  <person>
    <name>Rickard</name>
    <email>ri...@jb...</email>
    <module>Core</module>
    <module>Taglibs</module>
  </person>
  <person>
    <name>Maurice</name>
    <email>Ma...@vi...</email>
    <module>Taglibs</module>
  </person>
</people>

Example JSP:
<H2>Testing XML output</H2>
<webwork:bean name="webwork.test.PeopleList">
   <webwork:iterator name="people:person">
      <webwork:property name="name"/>(<webwork:property name="email"/>),
Modules:<BR>
      <webwork:iterator name="module">
         <webwork:property/><BR>
      </webwork:iterator>
   </webwork:iterator>
</webwork:bean>

Example HTML output:
      <name>Rickard</name>(<email>ri...@jb...</email>),
Modules:<BR>
      
         Core<BR>
      
         Taglibs<BR>
      
   
     
<name>Maurice</name>(<email>Ma...@vi...</email>),
Modules:<BR>
      
         Taglibs<BR>
-----

I hope the above is self-explanatory.

So, what do you think? Is this good enough? It was a bit tricky to get
this to work, but now it does. I'm just wondering if the above is too
simplistic, or if it enough to use XML with WebWork.

What major features are necessary to say "WebWork works with XML"?

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] optimizations - cool!

[Andrius J. <an...@li...>]

hi rickard,

I am not sure if this the result of the recent optimizations you introduced,
but with the fresh build of webworks I get some 3x performance gain for my
calendar component (it uses a 2 level iterator) - instead of 250 ms I get
something like 60 ms :)

will see if/how performance changes when I remove the jsp:include tags..

regards,
--andrius

[Webwork-user] WebWork optimizations

[Rickard <ri...@jb...>]

Hey

I have done some WebWork optimizations. First of all, the name expansion
algorithm ("$foo"->"bar") is now only done once for each tag instead of
for each time the tag is used. The bad news is that the Jasper JSP
compiler doesn't work as it should, and thus invalidates this.

Example:
<webwork:iterator>
  <webwork:property name="$foo"/>
<webwork:iterator>
In the above case "$foo" should only have to be resolved once (the first
loop) and then the result can be reused for all other iterations.
Unfortunately Jasper (the JSP engine in Tomcat) instantiates the
property tag *for each loop* thus making it impossible to do this
optimization!

I have notified the Tomcat dev mailing list and hopefully this will be
fixed, in which case you're going to see some performance enhancements
for tags inside iterators. Since this is very common the total effect
should be very good.

I have also changed the name resolution a bit so that $foo can mean
either "take value of foo parameter" or "take value of foo attribute"
(in that order). This means that in theory it should be possible to use
<@ include> instead of <jsp:include> for generic controls. However,
currently the controls contain JSP code that explicitly uses request
parameters, so it doesn't work yet.

If the code in the controls is changed so that either request parameters
or attributes can be used, then it will work well. This should improve
performance even more. Come to think of it, is there any reason to use
jsp:include at all? I.e. could we change the generic controls to
*always* get request attributes? That'd work in that case. Any
objections to this?

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] JSP Technology: Friend or Foe

[Rickard <ri...@jb...>]

(Brett is in CC)

Edwin DeSouza wrote:
> http://www-4.ibm.com/software/developer/library/w-friend.html?dwzone=web

Interesting read, but nothing new if you've been following Bretts
argumentation for awhile. :-)

I agree with all his points, and am glad to say that WebWork addresses
all of them (AFAICT). The one negative point that it does not address
(so far) is the fact that one can revert to using Java code in the
JSP's, but that's kind of hard to avoid. The solution to that would be
to make our own scripting engine that *only* supports the WebWork tags,
but I'm not particularly fond of that idea. 

So,
* WebWork does allow complete separation between content, presentation,
and code, by employing the "Pull JMVC" paradigm. (Note that XMLC is
"Push MVC" which is worse from a View/Controller separation point of
view. A "push MVC" technique makes it much more difficult to handle
multiple skins and reuse of actions the way that WebWork allows).
* WebWork pages can be edited with normal page editors, provided that
they don't throw away custom tags.
* WebWork can be used in a roundtrip fashion between designers and
programmers due to the simple, non-programmatic tag libraries.
* WebWork does not contain a scripting language cop-out (but since it is
JSP-based regular <%%> stuff can still be used)
* The above only refers to the case where JSP+WebWork taglibs is used
for presentation. There is nothing in WebWork that prevents any other
presentation technique to be used. The Action API and WebWork taglibs
are fully separated (although using them together *is* very convenient).

Brett, am I missing something?

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] Name collision (FIXED)

[Rickard <ri...@jb...>]

Hi!

"Maurice C . Parker" wrote:
> It looks great!  The only thing that I think might be desirable is using a : in the first position of the name to denote the top object in the object hierarchy.  For example ":foo:bar" would get you into the second level no matter how deep you are.  This is the same way that hierarchial filesystems work (just with slashes instead of colons).  I haven't had a chance to look at the new name resolution code, so I'm not sure that this even makes sense.

I could easily add :foo to get to the top. There would be no significant
performance penalty to do this.

> After I typed all this it occurred to me that maybe I can us the @ syntax to get to the original action bean, I just don't know how to do it.  If that's the answer, a little code snippet could probably get me there.

Do this in the beginning of the top JSP:
<webwork:property id="foo"/>

Since there is no "name" attribute WebWork will take the first value on
the value stack, which at the beginning happens to be the action itself.
This will then be bound to the attribute name "foo". Which you then can
access with "foo@". 

I can still add the ":foo" convention, but the above should help you.

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] Name collision (FIXED)

[Maurice C . P. <Ma...@Vi...>]

* Rickard Öberg (ri...@jb...) wrote:
> 
> Is this sufficient as naming rules?

It looks great!  The only thing that I think might be desirable is using a : in the first position of the name to denote the top object in the object hierarchy.  For example ":foo:bar" would get you into the second level no matter how deep you are.  This is the same way that hierarchial filesystems work (just with slashes instead of colons).  I haven't had a chance to look at the new name resolution code, so I'm not sure that this even makes sense.

Why functionality like this might be attractive to me is the Jive/Webwork breeding I'm doing.  If you look at the threaded messages, they are recursive in nature.  I could be at any level but still need info from the original bean.

Here is the code that I use to thread the messages (actually it needs to go deeper when before going to production):


<webwork:iterator name="discussion">
  <%@ include file="message.jsp" %>
    <ul>
    <webwork:iterator>
        <%@ include file="message.jsp" %>
        <ul>
        <webwork:iterator>
            <%@ include file="message.jsp" %>
            <ul>
            <webwork:iterator>
                <%@ include file="message.jsp" %>
            </webwork:iterator>
            </ul>
        </webwork:iterator>
        </ul>
    </webwork:iterator>
    </ul>
</webwork:iterator>


Here is message.jsp:


<p>
<span class="messageSubject"><webwork:property name="subject"/></span>
<br>
<span class="messageByline">Posted by <webwork:property name="user:username"/>, <webwork:property name="fancyDate"/>.</span>
<br>
<span class="messageBody"><webwork:property name="body"/></span>
<br>
<span class="messageReply">
( <a href="CommentForm.action?forumID=<webwork:property name="forumID"/>&threadID=<webwork:property name="forumThread:ID"/>&messageID=<webwork:property name="ID"/>"/>Reply to this comment.</a> )
</span>
<br>
</p>  


In the link that I recreate at the end, I am using the the property forumID.  This is from the original action bean and I think that the upward search is hurting my performance.  If I were able to use name=":forumID", there is some potential to save cycles.

BTW, I did use jsp:include tag for all those message.jsp's (about 15 at the time) and it didn't take me long to replace them with the include directive (ouch! 8-).  It helped, but my performance is still way below what is typical for the Jive code heavy JSP's (Vodka skin for those who speak Jive 8-).  I haven't had a chance to do any profiling or anything to see if it is something that I did in my action bean or if it is Webwork that's slowing me down.  The parameter parsing stuff is the first thing that came to mind, only because it gets hit so heavily.

After I typed all this it occurred to me that maybe I can us the @ syntax to get to the original action bean, I just don't know how to do it.  If that's the answer, a little code snippet could probably get me there.

Later,

Maurice

[Webwork-user] JSP Technology: Friend or Foe

[Edwin D. <ede...@ja...>]

http://www-4.ibm.com/software/developer/library/w-friend.html?dwzone=web

Re: [Webwork-user] Name collision (FIXED)

[Rickard <ri...@jb...>]

"Maurice C . Parker" wrote:
> To try and explain this clearer I will denote jsp params by enclosing them in *'ss.
> 
> I am having some problems implementing selectmap.jsp using *key* and *value* as variables.  The problem is when the *key* has the same name as *name*.  This causes every option to be CHECKED.  This is because I can't figure out a way to explicitly access a parent property while at a child level.  The only way I know how is to cause the name to miss at the child level.
> 
> What I'm looking for is something like <webwork:property name="../$name"/> or <webwork:property name="/$name">.  IIRC, this is how its done in XSLT.

Support for name scoping has been added to CVS.

Here's how it works:
You can use relative scoping using "..". ".." moves one object up in the
chain of objects to try and find the name in. 
Example: "..:name"

You can use absolute scoping using @. The left part is a named attribute
in the request object, and the right part is the name of the property.
Example: "foo@bar:xyzzy"

Here's a snippet from a test I added to WebWorks test.jsp:
<webwork:bean name="webwork.test.Person" id="rick">
  <webwork:param name="name" value="Rickard"/>
  
  <webwork:bean name="webwork.test.Person">
    <webwork:param name="name" value="Maurice"/>
    
    name=<webwork:property name="name"/><BR>
    ..:name=<webwork:property name="..:name"/><BR>
    rick@name=<webwork:property name="rick@name"/><BR>
  </webwork:bean>
</webwork:bean>
---

We declare to Person beans, which has a property "name" that we want to
access. The declarations are nested, so both will be put on the "value
stack" (BTW, the whole name/value resolution code has been rewritten.
Much simpler/cooler/faster now, and works the way it should've from the
beginning). 

The outermost Person is Rickard, and the inner one is Maurice. So, when
we access the property named "name" it will go upwards in the value
stack, and find it in the bean named "Maurice". The second property is
named "..:name", which means that before we even start looking for
"name" we skip the first value on the value stack. The bean found is
hence the bean named "Rickard". The last property accessed is
"rick@name". Since we use the absolute form of names (using @) we first
get the value associated with the request attribute "rick". In our case
we have bound this to the "Rickard" bean by setting the id of the first
bean tag to "rick". WebWork then resolves "name" relative to this, which
means that it will get "Rickard" as result.

So, to conclude the result of the above is:
name=Maurice<BR>
..:name=Rickard<BR>
rick@name=Rickard<BR>

Is this sufficient as naming rules?

BTW, you can of course use .. as many times as you want: "..:..:..:foo"
is ok. However, you can only use @ in the beginning of a name.
"foo:bar@xyzzy" is not ok and will be resolved as "foo":"bar@xyzzy".

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] jsp:include

[Andrius J. <an...@li...>]

hi,

: I have now updated the generic controls to use this:
:    <%@ include file="/template/standard/controlheader.jsp" %>
:    <%@ include file="/template/standard/controlfooter.jsp" %>
: instead of jsp:include, i.e. a direct include on JSP compilation. Result
: is that the nr of includes is cut down to a third of what it used to be.
: Much much faster now! :-)))

hey, way cool :)

: It might be possible to do the same with the actual controls, which
: again would make things much faster. The problem is how to parameterize
: them, which I don't know yet.

imho, the parameters in the way they are passed to the components now are
statical in their nature, so doing something like you did above should be
also possible. or maybe webworks precompiler or smth? :))

--andrius:

Re: [Webwork-user] jsp:include

[Rickard <ri...@jb...>]

Andrius Juozapaitis wrote:
> it seems that jsp:include is a pretty expensive operation, therefore the
> idea of having includable components is nice, but results in heavy runtime
> penalties. any ideas on how to minimize/avoid this (except for having
> everything needed by the page statically linked into it)?

I have now updated the generic controls to use this:
   <%@ include file="/template/standard/controlheader.jsp" %>
   <%@ include file="/template/standard/controlfooter.jsp" %>
instead of jsp:include, i.e. a direct include on JSP compilation. Result
is that the nr of includes is cut down to a third of what it used to be.
Much much faster now! :-))) 

Changes are in CVS (only, will include this in 0.7 too).

It might be possible to do the same with the actual controls, which
again would make things much faster. The problem is how to parameterize
them, which I don't know yet.

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] Re: WebWork vs XMLC+Rocks

[Rickard <ri...@jb...>]

Edwin DeSouza wrote:
> If anyone wants to try out these examples in WebWork....
> http://xmlc.enhydra.org/EventHandler/

The EventHandler login example is done. It is in CVS. Very
straightforward, and it's *A LOT* simpler code than the original Rocks
code.

No major changes were required in WebWork to get this going. I did add
"clear()" to the Session mapping object for easy-to-code
logouts(=session.clear()). Basically the example is a composition of
techniques used in other examples were necessary.

The port was mostly done on a use-case basis, since I couldn't quite
figure out how the EventHandler code worked. It was very hard to get a
feeling for where things started and ended.

One tool that will be cool to create later on is the "WebWork
application web viewer": it will go through a WebWork app and figure out
what states exist, and how to go from one state to another, and present
this as a graph. Should be doable. :-)

I have now uploaded WebWork-0.7.zip to SourceForge FTP, but now the
admin interface is broken so I can't add it to the 0.7 release. Ah
well.. hang on, or simply get the CVS tar ball to use the latest stuff.

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] WebWork 0.7 - Struts example, input validation

[Hristo S. <hr_...@ya...>]

... And it would be nice if Brett McLaughlin 
comments on your JavaBeans-centric input validation 
in contrast to the XML-based input validation
framework he explained over four articles in JW.


Thanks Rickard,
Hristo


--- Rickard Öberg <ri...@jb...> wrote:
> WebWork 0.7 is available in CVS
> 
> I have just uploaded the last pieces of WebWork 0.7
> to CVS (SourceForge
> FTP is full so I will do the zip upload later).
> 
> There is a new ValidationEditorSupport base class
> available. This is
> useful for creating PropertyEditors that perform
> validation of input
> parameters, which can now be *completely
> externalized from the Actions*.
> This is a very important feature. This means that
> your Actions does not
> have to deal with validating the input, even if the
> input is strings
> that should simply conform to some given pattern.
> Instead you should
> create a BeanInfo object that describes what
> JavaBean PropertyEditors
> should be used for each attribute, and then the
> standard JavaBeans API
> will be used to interact with them for validation.
> If something goes
> wrong you can use the ValidationAware interface to
> get the exceptions,
> and as outlined in earlier post the
> ActionFormSupport base action does
> this so that the error messages are available to be
> used in, for
> example, generic JSP controls.
> 
> This is also important if you want to reuse Actions
> in different
> projects, where the only difference between the
> projects are the
> requirements on the input parameters (not uncommon
> scenario). Then, all
> you have to do is make a new set of PropertyEditors,
> and make sure the
> BeanInfo about the Action uses them. No changes to
> the Actions
> themselves would be needed.
> 
> In addition, the recent Struts example from
> JavaWorld has been fully
> converted to WebWork, and now uses the above
> validation techniques. The
> code is *very* clean and simple, and truly shows how
> WebWork makes it
> effortless to create web apps. Thor (the original
> author) is in CC of
> this post, and it would be great if you could
> comment on what you think
> about the adaptation from an implementation/design
> point of view.
> 
> regards,
>   Rickard
> 
> -- 
> Rickard Öberg
> 
> Email: ri...@jb...
> _______________________________________________
> Webwork-user mailing list
> Web...@li...
>
http://lists.sourceforge.net/mailman/listinfo/webwork-user


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/