"Nestel, Frank" wrote:
> Hi Craig,
>
> warning, this is long!
>
Hi Frank ... glad to hear from you. See below.
If you are interested in discussing the details of Struts, you might
want to
join the STRUTS-USER mailing list at <http://jakarta.apache.org> rather
than
occupying bandwidth on JSP-INTEREST, which should be more general
purpose.
>
> I toyed arround last weekend with the Struts tools, but I'm still
> unsatisfied. The basic idea as well as the basic approach is very
> cool anyway. I'd like to stay closer to the JSP/Servlet framework as
> Webmacro and freemarker, but have a better separation of functionality,
> layout and data.
>
> Some points:
>
> * The TextareaTag is broken: Accessing rows and cols attributes, certain
> Attributes (like wrapping) of HTML are not available for the struts-tag.
>
Some patches to the textarea tag were posted a couple of nights ago that
fixed
the basic syntax of the generated tag, and correctly used rows and cols
as the
attributes. Ideas for extensions to the tags are welcome -- including
additional HTML attributes to be supported. However, pardon my
ignorance, but I
don't see any mention of a "wrapping" attribute in HTML 4.0???
One particular area of enhancement focus will be the optional ability to
generate JavaScript functions for client side validation for things like
"required field" or "must be an integer".
>
> * Generally it looks like many HTML attributes are missing from the taglib.
That problem can be easily addressed -- I wanted to get the basic
framework
working first.
>
> * Maybe it would be nice to have more control whether the text is editable
> or read/only or not even viewed with custom tags. I.E. with your user
> registration, I'd like to use the same bean and the same jsp to register
> and edit my registration data, but in the latter case I shouldn't be able
> to change my unique user id any more AND I DONT WANT TO DO JAVA CODING IN
> IN MY JSP :-)
If it is editable, use this:
<struts:text name="xyz"/>
if it is not editable, use this:
<struts:property name="xyz"/>
If it needs to go back and forth (i.e. the "disabled" attribute on an
input
field), that will need to wait for an enhancement to the text tag.
>
> * Having the System text properties in many languages would be nice anyway.
Anyone willing to do the translations? I would be happy to check in the
appropriate resource bundles for these!
>
> * Isn't there some means to implement an "else" Tag to your if tags (I know
> there are intrinsic problems with the Taglib-Syntax). Would be so nice.
> Having "if a endif if not a endif" is a source of easy mistakes.
Offhand, I cannot think of a really elegant way to do this -- but I'm
going to
experiment with something like the following:
<struts:ifCondition ...>
...
</struts:ifCondition>
<struts:else>
...
</struts:else>
where the "if" tag would remember the result of the last conditional
evaluation
somewhere internally, and the "else" tag could simply reverse that
result. Have
to make sure this works with nested conditionals, too. Does that sound
like a
reasonable syntax?
>
> * The locale/message support is very nice, but instead of hanging my
> application
> with a NullPointerException, I'd like another behaviour if an undefined
> text is requested: Write s.th. in the log file, and show the Message id
> to the presenting tag/servlet. E.g. if a MessageTag requests
> franks.cool.text,
> which is missing. Write a warning in a log file and return
> de_DE:franks.cool.text
> to the application. This behaviour should be (maybe switchable) at low
> level
> in the application.
How about a reserved message key that is used whenever an unknown key is
requested? That way, you can have your cool message, and I can have my
null
return if I want :-).
> * Switching locales seems to be broken. I implemented an Action to set the
> session locale to a certain value, but still get german text unless it
> is missing and i get the english ones you provided.
I assume you actually have the appropriate German resource bundle as
well,
right? I will look at that.
>
> * Consider to have some classes (e.g. the Message obtaining/caching) as
> singletons in JVM Space instead of Application space. I'd rather like
> to have a MessageBundle.getInstance() anywhere in my java, than to access
> the objects via requests, session and application objects. Hmm at a second
> thought I am not convinced completely if this is a good idea, but its
> an idea anyway.
Singletons in a servlet container environment are not portable. Most
servlet
containers implement a custom class loader for each web application
(some for
each servlet) -- and statics are not shared across class loaders. That
is why
you are encouraged to use servlet context attributes (i.e. application
scope
beans in JSP) for information sharing within an app, and external media
(databases, directory servers, files, EJBs, ...) for sharing between
applications.
Think about the implications if sharing across apps really was allowed
-- do you
*really* want some other web app running in the same container to be
able to
scribble on your critical global variables? We might as well go back to
COMMON
blocks in Fortran :-).
>
> * Consider having a tag for a jsp to check weather it is accessed directly
> or
> via the controler servlet, forwarding the request to some neutral page in
> the
> prior case.
It would not be tough to do this -- simply check the request URI (on a
forward,
it wil still be the original URI pointing at the controller servlet).
You would
have to know what <servlet-mapping> pattern you are using for the
controller
servlet to make the decision, but that seems possible.
A similar "nice to have" would be a tag to check for the existence of a
particular session attribute, and forward if it is missing. That would
be
useful for checking whether the user is currently logged in or not.
> Even nice would be if sun would allow some fixed
> initialization
> code for a JSP, when a taglib is requested by it, but I don't know where
> to
> send that idea. Second thinging shows: A taglib would then need to have
> an initialization at JVM, Server, Application, Session, Request and Page
> scope
> :-)
Ideas for improving the specs should go to the feedback EMAIL addresses
on the
front covers. In the case at hand:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
depending on whether its a servlet thing or a JSP thing.
What I do for initialization is to use a startup servlet, which will
create and
configure the objects I need, and store them in the servlet context
attributes
(for example, the MessageResources bundle). The custom tag instance has
access
to this (through the PageContext), so it is quite reasonable. Because
tag
instances get created quite often (they are not accessed in a
multithreaded
manner like servlets are), I would not want to do a lot of heavy lifting
at
every tag instance creation.
>
> * Customization of process method is a lot of work to do, like starting from
>
> scratch. Couldn't be that more modularized so that I can restrict myself
> to
> the essential coding (I started programming s.th. like having a process
> function which essentially returns the JSP URI, not caring about
> initialization
> and forwarding, when I realized it pulled me away from the application I
> need to program and might be different with the next struts-edition...)
Are you speaking of the process() method in ActionServlet? If so, the
easiest
way to customize the behavior would be to subclass ActionServlet and
just
override that method. If you just want to do some special logic first
and then
do the standard logic, it's pretty easy:
protected void process(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
... do something special here ...
... if it falls through, use the standard logic ...
super.process(request, response);
}
Or, you can replace the entire process() method with your own handling.
Of
course, my assumption is that you wouldn't have bothered using
ActionServlet in
the first place if you didn't want what the process() method does for
you, like
automatic handling of the form bean :-).
>
> Together with the idea of self validating FormBeans (having a own validate
> method it should be possible to obtain very short process methods for many
> standard cases.
As mentioned above, I'd like to see the ability to optionally create
client-side
validations in JavaScript as well.
Self-validating form beans sound cool at first blush, but consider one
issue
about the process flow -- one of the roles of the form bean itself is to
faithfully represent the last set of input fields that the user entered
(whether
the whole transaction is semantically valid or not). If the setter
methods in
your form bean, for example, were to through IllegalArgumentException on
invalid
values, your form bean would not be completely up to date -- so that
when you
redisplayed the the form to the user again, it wouldn't show the bad
value that
he/she actually entered.
I would suggest that validation be done either in the action class
itself, or in
the "data access layer" bean or EJB that actually represents your
business
objects.
>
> * Consider a different inner error format, not using a vector but a
> hashtable
> and give the JSP another custom tag, to show the error at the position
> created (by having a entryField->Error mapping in the Hashtable)...
>
> * What I really liked would be to have the whole application abstract
> automaton
> layed out in the action.xml, e.g. there should be a mechanism to reference
> a
> link just by name (from a Hashtable instead of the getSuccess(),
> getFailure()
> thingie) and a custom tag for the JSP which is s.th. like a inner link and
> does not even contain a HREF but rather a NAME of a link from the recent
> action.xml. Currently certain links are both in the action.xml and in the
> JSP source code.
> I fear, to imlement this one had to change quite a lot from the struts
> framework, keeping rather the spirit than the mechanics.
>
Can you do what you want by extending the ActionMapping implementation
class
with additional properties? After all, the "success" and "failure"
properties
are not part of the standard action class -- they are extensions defined
by the
example application. There is no limit to the number of such properties
you can
add (although there is no current support for an "array" or "hashtable"
type
approach). I'd have to think about how you could initialize such things
in a
generic way -- perhaps with some sort of element nested inside an
<action>.
>
> * Give me an easy slot to plug in a XSLT Transform engine (not necessarily
> cocoon,
> but at least some XSL postprocessing, like piping output once through an
> choosen XSL)
>
> Well, maybe it is a different project, but then it had to copy a lot of code
> from struts :-)
>
Hey, this project is "Struts", not "Kitchen Sink" :-).
Actually, plugging in an XSLT transform is really a servlet container
level
issue. In fact, some mechanism for defining portable filtering
(including XSLT
transformations) at the container level is being discussed in the next
spec rev.
In the mean time, I'm planning to let you incorporate some sort of
filtering
with a Struts tag like this:
<struts:xsl stylesheet="xyz.xsl">
... the body of your JSP page which ...
... now renders XML not HTML ...
</struts:xsl>
based on the "xsl" taglib in the jakarta-taglibs project at
<http://jakarta.apache.org>.
>
> I'd like to test/use that system but I doubt my personal schedule leaves me
> much time to do so. Any specific idea, how I could join the development at a
>
> slow rate?
>
Simply continue throwing out good ideas (on the STRUTS-DEV mailling
list) and
you'll make my day. I want to start bouncing approaches off the
developer's
list before implementing them. Of course, specific code contributions
are
always welcome too, but they are not required.
>
> When are the next updates coming :-)
>
Nightly builds are already being generated. Now that I'm back from
JavaOne (and
almost caught up on sleep :-), you'll see progress as my personal
schedule
permits. Others have expressed interest in helping as well -- the more
the
merrier.
>
> Cheers,
> Frank.
>
Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
