webwork-user — WebWork users mailing list

Re: [Webwork-user] Interactive documentation

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

"Maurice C . Parker" wrote:
> I was just about to begin documenting the template controls and was wondering if there were any documentation standards that should be followed.  Is everything to be done plaintext, HTML, Docbook, or something else?
> 
> I was going to put links next to the controls on the form test page to go to a page that had the control on it, show the code used to include it, and document the required and optionional parameters.  This would be similar to how Tomcat's documentation is merged with it's demo system.  Then I noticed that there was already a doc directory, and some standard maybe should be followed.
> 
> Suggestions?

I'm open. If there are no major wishes on this, you may choose to do it
any way you please. 

I usually do it in plain HTML (using only <pre> <h?> <p>), and use a
styles.css to get it to look decent. See any of my projects on
dreambean.com for examples. That's one ok way to do it.

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] Interactive documentation

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

All,

I was just about to begin documenting the template controls and was wondering if there were any documentation standards that should be followed.  Is everything to be done plaintext, HTML, Docbook, or something else?

I was going to put links next to the controls on the form test page to go to a page that had the control on it, show the code used to include it, and document the required and optionional parameters.  This would be similar to how Tomcat's documentation is merged with it's demo system.  Then I noticed that there was already a doc directory, and some standard maybe should be followed.

Suggestions?

Maurice

[Webwork-user] WebWork Design Goals

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

Rickard,
Do you have a set of Design Goals for WebWork?  Here is a start -- please
add/modify....

1)  Web Designer NEVER has to touch Java code.
2)  EASILY create multiple "Web Skins" for a application
3)  EASILY change Look and Feel.
4)  EASILY change Layout on a given Web Page.
5)  EASILY change Flow among Web Pages.
6)  EASILY move *existing* data elements from one page to another.
7)  EASILY integrate with various backend infrastructures.
8)  EASILY reuse components.

There must be many more....

Edwin.

[Webwork-user] I18n and more

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

Hey

Following Edwins advice I have begun converting the JavaWorld article on
i18n to WebWork. It is pretty straightforward, aside from the fact that the
original really is *JSP* with all that comes with that *shiver*. So, a bit
of "shaping up" has been done, which made it easier to read, but also a
little bigger in terms of number of classes.

Nevertheless, it was fairly easy to do so, and I'm very glad I did it
because it showed two things that are missing from WebWork. Two tags to be
precise.

First of all, currently generic components are now done as small
jsp:included JSP's which are customized with parameters. They all have a
"label" parameter which denotes the label of the component. The problem is
that it is not possible to have dynamic content for the label in any easy
way. The reason is the way it is supplied, which is as a jsp:param.
jsp:param has an attribute "value" which has a runtimeexpression as value.
This does indeed allow for extraction of dynamic content for the value, but
it would be nicer to be able to use WebWork properties.

I.e. instead of:
<jsp:param name="label"
value="<%=((SomeAction)pageContext.getAttribute("result")).getTexts().getStr
ing("somefield.label")%>"/>
I would want to do:
<jsp:param name="label"><webwork:property
name="texts:somefield.label"/></jsp:param>
i.e. let the body of the param tag be its value.

This is not how jsp:param works, but I have already created a webwork:param
which works like the way I want it to for the URL tag. What I will do now is
to adapt it to also work with a new webwork:include tag, which will be a
replacement for jsp:include. By doing this we can i18n'alize components'
labels much easier. I hope you see how by the above.

The second thing that is needed is a "quick action" for formatting output.
The Actions in WebWork are somewhat coarsegrained and are used for either
page or component processing. However, in the i18n example there is a place
where a currency is converted to another currency, and the currency name is
appended. E.g. $1 is converted into 8.93 SEK. This kind of field-by-field
processing is a bit cumbersome to do as Actions. I have actually done that
with this particular example, and it looked something like this:
<jsp:include page="i18n.ConvertPrice?result=price.jsp" flush="true>
   <jsp:param name="price" value="1"/>
</jsp:param>
where price.jsp is:
<taglib ...>
<webwork:property name="realPrice"/>

So, all that happens in ConvertPrice is that a conversion to a given locales
currency is done. To use actions and includes for this is somewhat awkward
and obscure.

Here's is a suggestion for an alternative solution. Introduce a tag "action"
which takes an action name as parameter, and which is executed as usual, but
its result from execute() is ignored and instead the action is made
available (for use by the property tag, for example) during the execution of
its body. Like this:
<webwork:action name="i18n.ConvertPrice">
  <webwork:param name="price"><webwork:property name="cd:price"/>
  <!-- at this point the ConvertPrice action has been instantiated, its
setPrice method has been called, and execute() has also been called -->
  <webwork:property name="realPrice/> <!-- call getRealPrice on action to
print out the converted price including currency type indication -->
</webwork:action>

This would allow the MVC paradigm to be preserved, but allow for much more
lightweight usage than the usual action->jsp model. The above is somewhat
flawed still (how to determine when to call execute(), what happens if
execute() wants to show some error view, etc.) so if you have any ideas on
the above, speak up :-)

regards.
  Rickard

Re: [Webwork-user] Extending something other than ActionSupport

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

Tim White wrote:
>  Rickard has mentioned before that a form bean could extend a data class
> rather than ActionSupport.  How would this work in practice?  Do I need
> to manually implement all the stuff from ActionSupport or
> ActionFormSupport in the bean?  Am I going to run into polymorphism
> problems because I'm not extending ActionSupport?

Well, there are two ways (at least). If your data class is being written
explicitly to be used within WebWork, then you can let it subclass
ActionSupport, or ActionFormSupport (if you want the cooler error
message handling). 

However, I just stumbled into this problem myself since I had a data
object from EJB which should not have to deal with WebWork. 

To accomodate this I have now changed the *Support classes to be
concrete (i.e. not "abstract"). This allows them to be used through
delegation instead of subclassing. I.e. you can have your form bean
subclass the data bean, and also instantiate an ActionSupport class
which it can delegate to at appropriate times (e.g. execute would call
"as.getResult()" instead of "getResult()"). 

Is this sufficient? The above fixes has been added to CVS, but are not
yet available as a file release.

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] Extending something other than ActionSupport

[Tim W. <tl...@us...>]

Hi -

 Rickard has mentioned before that a form bean could extend a data class
rather than ActionSupport.  How would this work in practice?  Do I need
to manually implement all the stuff from ActionSupport or
ActionFormSupport in the bean?  Am I going to run into polymorphism
problems because I'm not extending ActionSupport?

Thanks,

Tim

RE: [Webwork-user] Localization i18n

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

Rickard,
If you build a Example which includes the "gudelines you have outlined in
previous posts" -- it will really help WebWork ;-)

Actually, I would recommend something like this:
-- Give the Example a Meaningful Name
-- Say it is an implementation of the Example specified in Article xyz
(include the URL).
-- Say why the WebWorkn implementation is better/simple than that in the
Article.

This way, you kill 2 birds with one stone.

Edwin

-----Original Message-----
From: Rickard Oberg [mailto:ri...@jb...]
Sent: Sunday, December 03, 2000 8:28 AM
To: Edwin DeSouza; web...@li...
Subject: Re: [Webwork-user] Localization i18n


> Rickard,
> Has there been any explicit effort/thought/desing to handle construction
of
> multilingual websites?  Maybe a example that can "on-the-fly" change
between
> Swedish, English, and a couple of other languages?
>
> Here is a relevant articles:
> http://www.javaworld.com/javaworld/jw-03-2000/jw-03-ssj-jsp_p.html

Incredibly complicated way of doing it IMHO. You can do that shop in WebWork
with much less effort, by employing the guidelines I have outlined in
previous posts.

> Here is an interesting post at Enhydra:
> http://www.enhydra.org/community/mailingLists/i18n-group/msg00034.html

Here we see an occurrence where the push MVC model of XMLC becomes
difficult. As outlined in previous posts, all of these problems go away
trivially in WebWork, simply because of how it has been designed to handle
these things (or rather, it hasn't been designed to handle these things, but
a direct side-effect of its design is its ability to handle i18n well :-)

/Rickard

[Webwork-user] Session map remove()

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

Rickard,

I needed to be able to remove session variables to do logouts.  This is my modification to Dispatcher to get it done:

Index: Dispatcher.java
===================================================================
RCS file: /cvsroot/webwork/webwork/src/main/webwork/servlets/Dispatcher.java,v
retrieving revision 1.3
diff -u -r1.3 Dispatcher.java
--- Dispatcher.java	2000/11/30 12:38:45	1.3
+++ Dispatcher.java	2000/12/03 18:53:49
@@ -357,5 +357,12 @@
          session.setAttribute(key.toString(), value);
          return get(key);
       }
+
+      public Object remove(Object key)
+      {
+		 Object value = get(key);
+         session.removeAttribute(key.toString());
+         return value;
+      }
    }
 }


Could you please add this to Dispatcher (or some similar functionality) so that session variables can be cleared?

Thanks,

Maurice

[Webwork-user] Using (Swing-) beans in webwork ...

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

Rickard-,
I think I can commit code/docos to sourceforge now!
Unfotunatelly, I'll be on a business trip for 3-4
days. But, when I get back I'll put some stuff for
orientation with WebWork (seems there is a lot of
confusion for what webwork is, what is in the source
tree and HOW THE TAGS WORK). I have to see if I can
recover all previous posts in both jBoss and Webwork
lists, with little cosmetics this would be a nice
"introduction".
About the idea of layering Swing components(JMenu) -
we should "adapt" them to the Action/SessionAware
interfaces. And that is where the JDK 1.3 Dynamyc 
proxy may come to help - why not generate dynamic
proxies whithin the Dispatcher.java servlet which now
instantiates the actions? I think similar things are
being done in JBoss and Orion app server when they 
adapt to the remote interfaces... Just an idea!

Hristo

> Just an observation... In one of your previous
> posts you create a menu based on java.util.Map
> Have you thought about using JMenu straight?
> It has a menber "getSubElements()". Now, if we can
> introspect "Object[] getPropery" in the webwork
tags,
> we could use JMenu and some other Swing widgets too.
> Imagine the code reusability!

Yes, that occured to me too, and I looked through the
Swing API and 
found
the getSubelements() stuff too. I haven't tested this
yet, but it 
should
work! :-)

regards,
  Rickard



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

Re: [Webwork-user] JSP and XML/XSL

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

> Rickard,
> You know it is going to happen.  As WebWork gains momentum -- people will
> want to use it with XML/XSL.  An example in this area would be great too.
>
> Here are some relevant links:
>
http://www.devx.com/upload/free/features/javapro/2000/08aug00/ww0008/ww0008-
> 1.asp
> http://www.javaworld.com/javaworld/jw-03-2000/jw-0331-ssj-jspxml_p.html
>
>
http://jakarta.apache.org/cvsweb/index.cgi/jakarta-taglibs/xsl/examples/web/
> jsp/

As outlined in the JW article, I think the most common use of XML with
WebWork is going to be as data structure (i.e. not for presentation
purposes, as is common with other web dev. frameworks).

So, most likely a couple of tags for traversing XML must be implemented, or
the "property" and "iterator" tags should be updated to allow for XML DOM
traversal (seems fairly simple).

Anyway, yes, it is something that must be dealt with, and I think it will be
a very valuable way of doing things.

regards,
  Rickard

Re: [Webwork-user] Localization i18n

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

> Rickard,
> Has there been any explicit effort/thought/desing to handle construction
of
> multilingual websites?  Maybe a example that can "on-the-fly" change
between
> Swedish, English, and a couple of other languages?
>
> Here is a relevant articles:
> http://www.javaworld.com/javaworld/jw-03-2000/jw-03-ssj-jsp_p.html

Incredibly complicated way of doing it IMHO. You can do that shop in WebWork
with much less effort, by employing the guidelines I have outlined in
previous posts.

> Here is an interesting post at Enhydra:
> http://www.enhydra.org/community/mailingLists/i18n-group/msg00034.html

Here we see an occurrence where the push MVC model of XMLC becomes
difficult. As outlined in previous posts, all of these problems go away
trivially in WebWork, simply because of how it has been designed to handle
these things (or rather, it hasn't been designed to handle these things, but
a direct side-effect of its design is its ability to handle i18n well :-)

/Rickard

Re: [Webwork-user] Localization i18n

[Rickard O. <ri...@te...>]

> Has there been any explicit effort/thought/desing to handle construction
of
> multilingual websites?  Maybe a example that can "on-the-fly" change
between
> Swedish, English, and a couple of other languages?

Some explicit, but most of it implicit. The explicit part is that WebWork
taglib names can refer to ResourceBundles. Like this:
<webwork:property name="texts:foo"/>
This can translate into the call getTexts().getString("foo") if the result
of getTexts is a ResourceBundle.

Also, ActionSupport has a method getLocale() which simply returns the system
locale. This can be overridden by apps that want to support
internationalization. Custom implementations of this method can, for
example, check the session for the chosen locale, or perhaps check the HTTP
request URI (let's say the URI is "/en/foo.jsp", then the getLocale() method
could extract the "en" part as the chosen locale). There are no rules from
WebWorks point of view on how to do this, but these are suggested
implementation options.

With regard to the implicit part of i18n, see my post on skins. Basically
one could have a skin per language, where there would be no functional
difference between each skin, but they would contain content with different
languages.

When I get the time (*phew* I'm a busy fellow, so any volunteers would be
appreciated on this one) I will update the HelloWorld app to do i18n for
English and Swedish.

/Rickard

[Webwork-user] Re: WebWork & competitors...

[Rickard O. <ri...@te...>]

webwork-users mailing list is in CC.

> I would like to ask you how you're positioning WebWorks: is it a template
> engine like WebMacro? Is it an MVC framework like Struts? Are you using
JSP
> plus a taglib for the View or some template language instead?

Excellent questions. First off, a little disclaimer: I am not an expert in
WebMacro or Struts, but I have at least cursory knowledge of their design
and workings. Some of my comments may be a little off. Let me know in such
case.

WebWork has two separate parts: the first part is the Action API including
the dispatcher servlet. This is the common part of any Model-2 JSP
framework, and is similar to how Struts works. The second part is the taglib
which is not coupled to the first part really, but is simply a set of useful
tags for extracting and presenting result data. So, you could use the Action
API with another presentation technique (such as WebMacro), or you could use
the WebWork taglib with another Model-2 dispatcher (like Struts).

When I began with the foundation for WebWork I looked at other similar
technologies, such as WebMacro, Struts, XML, Turbine, etc. What I found was
that many of them had good intentions, mostly in the field of getting MVC to
work in a web environment. However, they were all flawed in one way or the
other.

For example, some of them (XMLC and Turbine for example) used the "push MVC"
paradigm where the controller code knows about the view and "pushes" data
into the presentation layer. The drawback of this pattern is that it is
tough to apply several different views to one controller, and that one often
has to rely on XML/XSLT to get multiple client type support. XML/XSLT are
complex API's, and they are rather CPU and memory intensive. The coding was
very somewhat cluttered with things that required quite a bit of knowledge
about the API being used. For me, simplicity and clean code are imperative,
and also the ability to convey the semantics of what code should do with
minimal syntax. I.e. code should be simple, short, and to the point.

Struts is probably the technique that was the most similar to WebWork. In
fact, at one point I thought "why do another framework? this looks good
enough". Approximately five seconds later I changed my mind, and realized
how wrong that was. The main problem with Struts is its large API to do
things. There is quite a bit of API in there, and it is rather tied to
Servlets (which is not strange considering that the author, Craigh
McClanahan, is obviously tainted from his work with Tomcat). The API also
imposed quite a bit of implementation rules with regard to how things are
done. I wanted an API that was smaller, simpler, was not reliant on servlets
(for the sake of reusing controller code in Swing GUI's, but also to be able
to do automatic testing outside of a servlet engine), and did not impose
unnecessary restrictions on how things are done.

The result is WebWork. The one-line technical description of WebWork is "a
Model-2 pull HMVC web application framework"(HMVC=Hierarchical Model View
Controller. "Hierarchical" since a page can be broken down into components,
and each of them uses the MVC pattern). The base API is insanely simple
(basically the execute() method in the Action interface), the application
code is not reliant on servlets (unless the ServletAware interface is used,
but it is strictly optional), there are no restrictions on what should be
used as view technique, and the application developer is free to implement
all design decisions (how to compute result view, how to choose locale, how
to perform skinning, etc.) as they please. The last point may seem awkward,
since it is too much work for all application developers to do these things
all over again for each application, but this is alleviated by introducing a
bunch of support classes which provide default, and recommended, ways of
doing things. However, if the programmer chooses he can do things from
scratch or only do some things himself (for example, he can provide a
subclass of ActionSupport that implements getView() by requesting the view
for a particular action from a database instead of using the
views.properties file, which is merely the default implementation).

Also, great care has been taken so that writing actions is easy by using a
simple execution model. Basically the actions are JavaBeans, which means
that they have setX() methods for incoming parameters, execute() is called
to perform the action, and getX() methods are lastly called to retrieve the
result data. This ensures that all actions only contain the code that is
minimally required to perform the logic. There is no extra code to account
for the fact that it is being used within WebWork.

Then, the taglibs have also been adapted to this philosophy. They only
provide tags to extract and iterate over the result data so as to present it
through HTML or similar. I will try very hard to keep the nr of tags down to
a minimum so as not to pollute this model. I do not want to introduce tags
that, for example, execute SQL queries, since this is obviously things that
should be done in the actions themselves.

Finally, due to the design of WebWork there are quite a few things that are
amazingly simple to accomplish which most other have serious difficulties
with, or cannot do at all. I am mostly thinking about custom reusable web
components (which in WebWork is just implemented as parameterized JSP
pages), and skins (which are trivially implemented by using relative JSP
references. See other post to webwork-user for details on this).

All of this together gives you an incredibly flexible model that can do,
AFAICT, all that which a web development model is supposed to handle these
days, and yet does it without requiring the developer to learn large and
complex API's such as XML and XSLT. This is equally important as developer
training is becoming increasingly problematic as the number of technologies
needed to create web sites rise. KISS is the rule we all know and love ;-)

I hope this answers your question, and then some :-)

best regards,
  Rickard

Re: [Webwork-user] Menu Idea

[Rickard O. <ri...@te...>]

> Just an observation... In one of your previous
> posts you create a menu based on java.util.Map
> Have you thought about using JMenu straight?
> It has a menber "getSubElements()". Now, if we can
> introspect "Object[] getPropery" in the webwork tags,
> we could use JMenu and some other Swing widgets too.
> Imagine the code reusability!

Yes, that occured to me too, and I looked through the Swing API and found
the getSubelements() stuff too. I haven't tested this yet, but it should
work! :-)

regards,
  Rickard

Re: [Webwork-user] Web "Skins"

[Rickard O. <ri...@te...>]

> Rickard,
> How easy (any examples?) for creating "skins".

WebWork comes with a HelloWorld example that has two skins (called brief and
verbose).

Basically it comes to down to this. Assumptions:
* Action objects return JSP URL's that are relative (i.e. "foo.jsp" instead
of "/foo.jsp")
* All JSP's for the apps default skin is in the directory "/skin1"

So, if the following is executed:
/myapp/skin1/Foo.action?result=foo.jsp
the results will be viewed with:
/skin1/foo.jsp
All relative links within foo.jsp (<A HREF>'s and forms etc.) will be parsed
relative to /skin1, as usual.

This means that if you copy the /skin1 directory to /skin2 you now
immediately gave a new "skin". And using it is as simple as doing:
/myapp/skin2/Foo.action?result=foo.jsp
which will view
/skin2/foo.jsp

The use of skins can be used for many purposes. One could be to support many
kinds of clients, but another could be for internationalization, i.e. the
skins look exactly the same but the content text are in different languages.
And of course you can combine it. Let's say you have two client types
("simple" and "standard") and you want to support the languages English and
Swedish ("en" and "se" locales), then you would have four different skins
which could be organized as follows:
/simple/en -> simple style English
/simple/se -> simple style Swedish
/standard/en -> standard style English
/standard/se -> standard style Swedish

Now you can allow the user to select language and style in some preferences
dialog, and all you have to do is direct the user to the right initial
directory. From there on it is "business as usual".

I hope this clarifies how skins works in WebWork, and how they can be
applied for various purposes.

Note also that this is merely one way to do skins. There are of course many
other ways to accomplish the same thing. This technique does not rely on any
particular feature in WebWork other than the ability to have relative page
references as result values from execute().

regards,
  Rickard

[Webwork-user] WAP Example

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

Rickard,
Yet another possible example....

Here is a relevant link:
http://www.javaworld.com/javaworld/jw-06-2000/jw-0602-wap_p.html
http://www.xml.com/pub/a/2000/06/26/xmldevcon/wirelessapps.html

Regards,
Edwin.

[Webwork-user] JSP and XML/XSL

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

Rickard,
You know it is going to happen.  As WebWork gains momentum -- people will
want to use it with XML/XSL.  An example in this area would be great too.

Here are some relevant links:
http://www.devx.com/upload/free/features/javapro/2000/08aug00/ww0008/ww0008-
1.asp
http://www.javaworld.com/javaworld/jw-03-2000/jw-0331-ssj-jspxml_p.html

http://jakarta.apache.org/cvsweb/index.cgi/jakarta-taglibs/xsl/examples/web/
jsp/

[Webwork-user] Localization i18n

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

Rickard,
Has there been any explicit effort/thought/desing to handle construction of
multilingual websites?  Maybe a example that can "on-the-fly" change between
Swedish, English, and a couple of other languages?

Here is a relevant articles:
http://www.javaworld.com/javaworld/jw-03-2000/jw-03-ssj-jsp_p.html


Here is an interesting post at Enhydra:
http://www.enhydra.org/community/mailingLists/i18n-group/msg00034.html


Regards,
Edwin

[Webwork-user] WebWork Competitors

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

Hi folks,
While you strive to make WebWork the best Web App Framework...this article
talks about its various competitors...you may want to make sure that WebWork
addresses all these areas.

http://www.javaworld.com/javaworld/jw-11-2000/jw-1103-presentation_p.html



Regards,
Edwin.

[Webwork-user] Web "Skins"

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

Rickard,
How easy (any examples?) for creating "skins".

For example see Jive:
http://209.221.164.135/jive/description.jsp


Regards,
Edwin

[Webwork-user] Menu Idea

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

Rickard-,
Just an observation... In one of your previous
posts you create a menu based on java.util.Map
Have you thought about using JMenu straight?
It has a menber "getSubElements()". Now, if we can
introspect "Object[] getPropery" in the webwork tags,
we could use JMenu and some other Swing widgets too.
Imagine the code reusability!

Hristo

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

[Webwork-user] WebWork 0.5 - generic controls

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

WebWork 0.5 has been released, and is available for download from the
WebWork CVS and as a Zip file from the project homepage.

The major new addition from 0.4 is a bunch of extremely cool generic
form fields(Kudos to Maurice for this submission). They make it
EXTREMELY easy to create form fields, and they use a CSS stylesheet for
look&feel. There is also a new ActionFormSupport base class which should
be used by form actions. It adds a per-field error message handling
(i.e. you can specify that field "foo" has an error message "Foo was
bad").

How to use this is shown in the Form test, which includes all available
generic fields. The HelloWorld application has also been updated to use
this for the login and greeting construction forms. Very VERY nice.

You can of course add your own controls by copy/pasting/modiyfing the
existing ones.

I am so excited about this version that I can't express it in words!!!
:-))) Unless I am missing something WebWork seems to be ready to create
larger applications with. I think the next thing for me to do is to
start updating the EBS application to see if everything works as it
should.

As always, if you have any comments/bug reports/suggestions, let me
know.

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] Calling methods from views

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

Hey

"Maurice C . Parker" wrote:
> BTW, I will try to get the control array (aligned controls w/labels and error messages) done over the weekend.  I'll bundle it up with a couple examples and see if you want to include it with Webwork.

The HelloWorld example now uses this strategy in the login procedure.
I.e., if there is an error in a field (username missing for example)
then the error message is shown in red next to the field that was in
error. Pretty cool.

This is now in CVS. Still no go with SourceForge file upload; will try
again later.

If you want to make an enhancement to this you could try to make the
<name:field:error message> thing as a generic component (like the select
box). Shouldn't be too difficult.

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] WebWork 0.4; cooler than ever

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

All,

I made some important progress today. I have now implemented the
SessionAware interface that lets actions use the session without being
servlet-aware. I have updated the HelloWorld application to use this for
login functionality. This is a major breakthrough, since I think this
was an important step towards making WebWork suitable for real
applications.

I have also created a bunch of generic controls that you can reuse in
HTML forms. See the "formtest.jsp" example for details on how they work
and how to use. They are very very nice and easy to use. If you make any
useful controls and want them included in WebWork, let me know.

The "iterator" tag now works with Maps. This means that if the input to
the iterator tag is of type java.util.Map it will get its "entrySet" and
iterate over that. For each entry the java.util.Map.Entry properties
"key" and "value" are available. See the "formtest" examples and the
generic controls for details on how to use this.

SourceForge is out of diskspace on the incoming FTP so I can't upload a
zip to SF just yet. Use CVS to download the latest sources with the
above changes.

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

[Webwork-user] WebWork components: Works!!!

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

All,

I've been fiddling a bit with generic WebWork components. It works
GREAT!

Here's a somewhat complex example. This generic JSP component
"selectgroupmap.jsp":
<%@ taglib uri="webwork" prefix="webwork" %>

<SELECT NAME="<%=request.getParameter("name")%>">
<webwork:iterator name="$list">
<OPTGROUP LABEL="<webwork:property name="key"/>">
<webwork:iterator name="value">
<OPTION VALUE="<webwork:property name="key"/>" 
   <webwork:equals name="key"
value="$value">SELECTED</webwork:equals>><webwork:property
name="value"/></OPTION>
</webwork:iterator>
</OPTGROUP>
</webwork:iterator>
</SELECT>

included like this in a form:
Country:<jsp:include page="CountryMap.action?result=selectgroupmap.jsp"
flush="true">
  <jsp:param name="name" value="country"/>
  <jsp:param name="list" value="countries"/>
  <jsp:param name="value" value="country"/>
</jsp:include>

where CountryMap.java is:
public class CountryMap
   extends ActionSupport
{
   // Attributes ----------------------------------------------------
   Map countries;
   
   // Public --------------------------------------------------------
   public Map getCountries()
   {
      return countries;
   }
      
   // Action implementation -----------------------------------------
   public Object execute()
      throws Exception
   {
      countries = new HashMap();
      
      Map continent = new HashMap();
      continent.put("sv", "Sweden");
      continent.put("uk", "United Kingdom");
      continent.put("ge", "Germany");
      countries.put("Europe", continent);
      
      continent = new HashMap();
      continent.put("ch", "China");
      continent.put("in", "India");
      continent.put("ru", "Russia");
      countries.put("Asia", continent);
      
      continent = new HashMap();
      continent.put("us", "USA");
      continent.put("ca", "Canada");
      countries.put("North America", continent);
      
      return getResult();
   }
}

and the form that uses this control has getCountry() and setCountry()
(used for the "name" and "value" params to get the currently selected
item),
results in this HTML:
Country:

<SELECT NAME="country">

<OPTGROUP LABEL="Europe"><OPTION VALUE="sv" >Sweden</OPTION>
<OPTION VALUE="ge" >Germany</OPTION>
<OPTION VALUE="uk" >United Kingdom</OPTION>
</OPTGROUP>

<OPTGROUP LABEL="North America"><OPTION VALUE="ca" >Canada</OPTION>
<OPTION VALUE="us" >USA</OPTION>
</OPTGROUP>

<OPTGROUP LABEL="Asia"><OPTION VALUE="ru" >Russia</OPTION>
<OPTION VALUE="in" >India</OPTION>
<OPTION VALUE="ch" >China</OPTION>
</OPTGROUP>

</SELECT>
---

Is that cool or what!?! I've done a couple of other "controls" or
components, and it's just incredibly easy to work with and use.

I'm doing a bunch of these as examples and am including them with
WebWork, and am also doing an example form that shows how to use them.

Web development nirvana, here we come :-)

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...