You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Ed Hill <ed...@uiowa.edu> on 2002/01/07 21:37:46 UTC
Submission... tag library
Hello,
A few weeks ago, I mentioned in the struts-user list a tag library that we
are developing which at the time I called gui:table... I didn't have the
source ready to go at the time - but rather then trying to get it perfect in
isolation, I'll risk the public humiliation and go ahead and make available
what I have now and try to work with others who are interested in
helping me polish it up.
Currently, this taglib has a single key tag called "table" that takes a list
of objects and displays them as a table. It has various features
(alternating row colors, using a decorator for formatting, sorting,
pagination, etc...)
My goal over time will be to add other common "high-level" web display
patterns to the tag library, for example:
- display:table
- display:tree
- display:tabs
- display:inspector
- etc...
The source to this tag library is available at:
http://edhill.its.uiowa.edu/downloads/display.zip
Examples, showing usage can be found at:
http://edhill.its.uiowa.edu/display-examples/
Currently, documentation is little more then just the examples.
To be honest, my original intention was to donate this taglib to struts if
there was interest, as we are heavy struts users here at the U of Iowa, and
I wanted to give back if possible, but there is nothing "struts-specific"
about the taglib (other then using some struts-like naming conventions for
attributes), so it is probably more appropriately a candidate for the taglib
project, and as such, I have been working on getting the build process for
the tag working in a jakarta-taglib style.
I welcome any and all feedback and advice. If this taglib seems like
something that would be useful for either struts or taglibs, please let me
know, and I'll be happy to work with either group to get it put into CVS and
on a more serious release schedule.
I am currently being presumptuous, and have the taglib living in the
org.apache.taglibs.display package, but if this doesn't seem like something
that would be of use to taglibs, I will certainly change the packaging to
something more appropriate.
Thanks.
-Ed Hill (ed-hill@uiowa.edu)
Software Developer - Information Technology Services - University of Iowa
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Submission... tag library
Posted by Don Saxton <eu...@pacbell.net>.
yes, this will be a significant contribution. Just the right stuff for a
public taglib, it will be interesting to see how it evolves. I especially
like the writing in the examples and its sensitivity to usage. I hope you
get a chance to carry that over to the documentation you suggest.
bravo.
----- Original Message -----
From: "Ed Hill" <ed...@uiowa.edu>
To: <st...@jakarta.apache.org>; <ta...@jakarta.apache.org>
Sent: Monday, January 07, 2002 12:37 PM
Subject: Submission... <display:table...> tag library
> Hello,
>
> A few weeks ago, I mentioned in the struts-user list a tag library that we
> are developing which at the time I called gui:table... I didn't have the
> source ready to go at the time - but rather then trying to get it perfect
in
> isolation, I'll risk the public humiliation and go ahead and make
available
> what I have now and try to work with others who are interested in
> helping me polish it up.
>
> Currently, this taglib has a single key tag called "table" that takes a
list
> of objects and displays them as a table. It has various features
> (alternating row colors, using a decorator for formatting, sorting,
> pagination, etc...)
>
> My goal over time will be to add other common "high-level" web display
> patterns to the tag library, for example:
>
> - display:table
> - display:tree
> - display:tabs
> - display:inspector
> - etc...
>
> The source to this tag library is available at:
>
> http://edhill.its.uiowa.edu/downloads/display.zip
>
> Examples, showing usage can be found at:
>
> http://edhill.its.uiowa.edu/display-examples/
>
> Currently, documentation is little more then just the examples.
>
> To be honest, my original intention was to donate this taglib to struts if
> there was interest, as we are heavy struts users here at the U of Iowa,
and
> I wanted to give back if possible, but there is nothing "struts-specific"
> about the taglib (other then using some struts-like naming conventions for
> attributes), so it is probably more appropriately a candidate for the
taglib
> project, and as such, I have been working on getting the build process for
> the tag working in a jakarta-taglib style.
>
> I welcome any and all feedback and advice. If this taglib seems like
> something that would be useful for either struts or taglibs, please let me
> know, and I'll be happy to work with either group to get it put into CVS
and
> on a more serious release schedule.
>
> I am currently being presumptuous, and have the taglib living in the
> org.apache.taglibs.display package, but if this doesn't seem like
something
> that would be of use to taglibs, I will certainly change the packaging to
> something more appropriate.
>
> Thanks.
>
> -Ed Hill (ed-hill@uiowa.edu)
> Software Developer - Information Technology Services - University of Iowa
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AspectJ and Struts Exception handling:
Posted by Nicholas Lesiecki <ni...@eblox.com>.
Well, yes you will have to use new syntax--as my example illustrated. And
yes, AOP is a relatively new paradigm, with the associated wrinkles and
complexity. However, much like OO, it has the potential to revolutionize the
way we program. For instance, instead of using System.err, I could use Log4j
and apply my exception handling changes to the whole codebase in 3
minutes...
I just wanted to bring it up so that people could start thinking about its
potential application to Struts.
Cheers,
Nick
-----Original Message-----
From: John Yu [mailto:john@scioworks.com]
Sent: Friday, January 11, 2002 3:13 AM
To: Struts Developers List
Subject: Re: AspectJ and Struts Exception handling:
I did some research on aspect-oriented programming (AOP) about a year ago.
It is a relatively new paradigm. The current stage of AOP is like the stage
of OOP twenty years ago: AOP introduces new syntax. To use it you need a
pre-processor (that's what AspectJ does). (As an analogy, twenty years ago,
C++ introduced new syntax to C. To use C++, you needed C-front to
pre-process C++ into C.)
I personally find AOP intriguing. However, as with any cutting-edge
technologies, we need to treat it with caution. As far as I can see, the
major implication is that developers will no longer write code in Java; we
will write code in "Java++"--Java with AOP syntax. :)
--
John
At 03:51 pm 10-01-2002 -0700, you wrote:
>Hello,
>
>A while back Rick Hightower submitted a request to change the way Struts
>handles errors. His problem (and mine) is that Struts tends to catch
>exceptions and throw different exceptions indicating the problem. Needless
>to say this can badly obscure the original cause of the error.
>
>So today I set about remedying it using AspectJ--an aspect oriented
>extension to Java produced by Xerox PARC (http://www.aspectj.org). I added
>the following aspect to the org.apache.struts package:
>
>public aspect ExceptionLogger+AHs-
>
> before(Throwable e) : args(e) +ACYAJg- handler(Throwable+-)+AHs-
> System.err.println(+ACI-Exception caught in the Struts
> framework:+ACI-)+ADs-
> e.printStackTrace(System.err)+ADs-
> +AH0-
>+AH0-
>
>Then I compiled Struts with an Ant task for AspectJ compilation:
>
>+ADw-target name+AD0AIg-compile.library+ACI-
>depends+AD0AIg-prepare.library+ACI-
> description+AD0AIg-Compile Struts library files+ACIAPg-
> +ADw-ajc srcdir+AD0AIgAkAHs-src.share.dir+AH0AIg-
> destdir+AD0AIgAkAHs-build.home+AH0-/library/classes+ACIAPg-
> +ADw-classpath refid+AD0AIg-compile.classpath+ACI-/+AD4-
> +ADw-/ajc+AD4-
> +AFs-...task continues as normal...+AF0-
>
>Now all exceptions caught in the Struts framework are automatically logged
>to System.err.
>
>So my question is:
>
>Should we consider the use of AspectJ in Struts? This would potentially
>have no effect on the users of the framework, but could be valuable for
>implementing logging and error-handling policies. The above code could be
>modified to write to a log4j log if that would be more convenient.
>
>Does this intrigue anyone? Should we continue investigation?
>
>Cheers,
>
>Nicholas Lesiecki
>
>(For more info on AspectJ, look for my forthcoming article on IBM's
>developerWorks.)
>
>Technical Team Lead
>eBlox, Inc.
>(520) 615-9345 x104
>Check out my new book+ACE-:
>Java Tools for Extreme Programming: Mastering Open Source Tools, including
>Ant, JUnit, and Cactus
>
>http://www.amazon.com/exec/obidos/ASIN/047120708X/
>
>
>
>
>--
>To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
>For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
Scioworks Camino - "Rapid WebApp Assembly for Struts"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AspectJ and Struts Exception handling:
Posted by John Yu <jo...@scioworks.com>.
I did some research on aspect-oriented programming (AOP) about a year ago.
It is a relatively new paradigm. The current stage of AOP is like the stage
of OOP twenty years ago: AOP introduces new syntax. To use it you need a
pre-processor (that's what AspectJ does). (As an analogy, twenty years ago,
C++ introduced new syntax to C. To use C++, you needed C-front to
pre-process C++ into C.)
I personally find AOP intriguing. However, as with any cutting-edge
technologies, we need to treat it with caution. As far as I can see, the
major implication is that developers will no longer write code in Java; we
will write code in "Java++"--Java with AOP syntax. :)
--
John
At 03:51 pm 10-01-2002 -0700, you wrote:
>Hello,
>
>A while back Rick Hightower submitted a request to change the way Struts
>handles errors. His problem (and mine) is that Struts tends to catch
>exceptions and throw different exceptions indicating the problem. Needless
>to say this can badly obscure the original cause of the error.
>
>So today I set about remedying it using AspectJ--an aspect oriented
>extension to Java produced by Xerox PARC (http://www.aspectj.org). I added
>the following aspect to the org.apache.struts package:
>
>public aspect ExceptionLogger+AHs-
>
> before(Throwable e) : args(e) +ACYAJg- handler(Throwable+-)+AHs-
> System.err.println(+ACI-Exception caught in the Struts
> framework:+ACI-)+ADs-
> e.printStackTrace(System.err)+ADs-
> +AH0-
>+AH0-
>
>Then I compiled Struts with an Ant task for AspectJ compilation:
>
>+ADw-target name+AD0AIg-compile.library+ACI-
>depends+AD0AIg-prepare.library+ACI-
> description+AD0AIg-Compile Struts library files+ACIAPg-
> +ADw-ajc srcdir+AD0AIgAkAHs-src.share.dir+AH0AIg-
> destdir+AD0AIgAkAHs-build.home+AH0-/library/classes+ACIAPg-
> +ADw-classpath refid+AD0AIg-compile.classpath+ACI-/+AD4-
> +ADw-/ajc+AD4-
> +AFs-...task continues as normal...+AF0-
>
>Now all exceptions caught in the Struts framework are automatically logged
>to System.err.
>
>So my question is:
>
>Should we consider the use of AspectJ in Struts? This would potentially
>have no effect on the users of the framework, but could be valuable for
>implementing logging and error-handling policies. The above code could be
>modified to write to a log4j log if that would be more convenient.
>
>Does this intrigue anyone? Should we continue investigation?
>
>Cheers,
>
>Nicholas Lesiecki
>
>(For more info on AspectJ, look for my forthcoming article on IBM's
>developerWorks.)
>
>Technical Team Lead
>eBlox, Inc.
>(520) 615-9345 x104
>Check out my new book+ACE-:
>Java Tools for Extreme Programming: Mastering Open Source Tools, including
>Ant, JUnit, and Cactus
>
>http://www.amazon.com/exec/obidos/ASIN/047120708X/
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
Scioworks Camino - "Rapid WebApp Assembly for Struts"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AspectJ and Struts Exception handling:
Posted by Donnie Hale <do...@haleonline.net>.
I just posted a message to commons about aspectj. :) Very, very cool stuff! What I'd like to see next from that arena is the ability to define pointcuts and aspects dynamically rather than with a recompile.
Donnie
> -----Original Message-----
> From: Nicholas Lesiecki [mailto:nick@eblox.com]
> Sent: Thursday, January 10, 2002 5:52 PM
> To: Struts Developers List
> Subject: AspectJ and Struts Exception handling:
>
>
> Hello,
>
> A while back Rick Hightower submitted a request to change the way
> Struts handles errors. His problem (and mine) is that Struts
> tends to catch exceptions and throw different exceptions
> indicating the problem. Needless to say this can badly obscure
> the original cause of the error.
>
> So today I set about remedying it using AspectJ--an aspect
> oriented extension to Java produced by Xerox PARC
> (http://www.aspectj.org). I added the following aspect to the
> org.apache.struts package:
>
> public aspect ExceptionLogger{
>
> before(Throwable e) : args(e) && handler(Throwable+){
> System.err.println("Exception caught in the Struts framework:");
> e.printStackTrace(System.err);
> }
> }
>
> Then I compiled Struts with an Ant task for AspectJ compilation:
>
> <target name="compile.library" depends="prepare.library"
> description="Compile Struts library files">
> <ajc srcdir="${src.share.dir}"
> destdir="${build.home}/library/classes">
> <classpath refid="compile.classpath"/>
> </ajc>
> [...task continues as normal...]
>
> Now all exceptions caught in the Struts framework are
> automatically logged to System.err.
>
> So my question is:
>
> Should we consider the use of AspectJ in Struts? This would
> potentially have no effect on the users of the framework, but
> could be valuable for implementing logging and error-handling
> policies. The above code could be modified to write to a log4j
> log if that would be more convenient.
>
> Does this intrigue anyone? Should we continue investigation?
>
> Cheers,
>
> Nicholas Lesiecki
>
> (For more info on AspectJ, look for my forthcoming article on
> IBM's developerWorks.)
>
> Technical Team Lead
> eBlox, Inc.
> (520) 615-9345 x104
> Check out my new book!:
> Java Tools for Extreme Programming: Mastering Open Source Tools,
> including Ant, JUnit, and Cactus
>
> http://www.amazon.com/exec/obidos/ASIN/047120708X/
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AspectJ and Struts Exception handling:
Posted by Nicholas Lesiecki <ni...@eblox.com>.
Hello,
A while back Rick Hightower submitted a request to change the way Struts handles errors. His problem (and mine) is that Struts tends to catch exceptions and throw different exceptions indicating the problem. Needless to say this can badly obscure the original cause of the error.
So today I set about remedying it using AspectJ--an aspect oriented extension to Java produced by Xerox PARC (http://www.aspectj.org). I added the following aspect to the org.apache.struts package:
public aspect ExceptionLogger{
before(Throwable e) : args(e) && handler(Throwable+){
System.err.println("Exception caught in the Struts framework:");
e.printStackTrace(System.err);
}
}
Then I compiled Struts with an Ant task for AspectJ compilation:
<target name="compile.library" depends="prepare.library"
description="Compile Struts library files">
<ajc srcdir="${src.share.dir}"
destdir="${build.home}/library/classes">
<classpath refid="compile.classpath"/>
</ajc>
[...task continues as normal...]
Now all exceptions caught in the Struts framework are automatically logged to System.err.
So my question is:
Should we consider the use of AspectJ in Struts? This would potentially have no effect on the users of the framework, but could be valuable for implementing logging and error-handling policies. The above code could be modified to write to a log4j log if that would be more convenient.
Does this intrigue anyone? Should we continue investigation?
Cheers,
Nicholas Lesiecki
(For more info on AspectJ, look for my forthcoming article on IBM's developerWorks.)
Technical Team Lead
eBlox, Inc.
(520) 615-9345 x104
Check out my new book!:
Java Tools for Extreme Programming: Mastering Open Source Tools, including Ant, JUnit, and Cactus
http://www.amazon.com/exec/obidos/ASIN/047120708X/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building Form Beans from XML Schema?
Posted by Jon Ferguson <fe...@ieee.org>.
Arron,
I agree with the analysis. There are of course other tools that do similar things
(including the Digester) but I've seen no others that do all three (XML/Schema/SQL)
at least opensource. It seems like a natural way to proceed in order to automate
some of this stuff. When I noticed that you could get Castor to generate beans with
the validate method I thought the author probably had Struts in mind.. If I get a
chance, I'll look into it further.
Thanks,
Jon
Arron Bates wrote:
> Jon,
>
> I'm quite certain the parser has the ability, it just doesn't do it.
> It's the generation of the Java code which is stopping it. I would think
> you could hack it, so when an object's setter is called automatically
> call it's validate() method (which the system creates both, so all you'd
> have to hack is when and where) for each object continuing to set all
> data (it carries invalid data quite happily, only complains when you ask
> it to marshal the document out or validate it) and remember all the
> validation errors which were thrown and just pop them into the pile for
> Struts. Could be groovy... but it's not an out-of-the-box ability.
>
> I've only had the chance to use the schema side of the matter. We use it
> to create the XML documents against the schema, when we have to do
> something which requires XML. I don't think my current client is a
> particular fan of XML per-se.
>
> Arron.
>
> Jon Ferguson wrote:
>
> >Arron,
> >
> >Thanks for the hands-on. Shame really.. surely the parser provides this data..
> >wonder if there's another way to 'compile' that information into a method.
> >
> >BTW, have you used Castor's Object-Relational mapping? The second half of the
> >equation would be to use that to persist the populated beans from within the
> >Action.
> >
> >Cheers,
> >
> >Jon
> >
> >Arron Bates wrote:
> >
> >>I've tried to do this with Castor generated objects. Problem is though,
> >>is that the errors are not fine grained at all.
> >>You validate the document by calling the validate() method on the top
> >>node, and you get a yes or a no.
> >>You can do this for all of the sub objects, but it's just that, you
> >>still have to implement the field validation yourself.
> >>
> >>Naturally you can't play any tricks with the calling of property methods
> >>to work around various issues as your objects are locked down to the
> >>automation process.
> >>
> >>Otherwise it's quite excellent.
> >>
> >>Arron.
> >>
> >>Jon Ferguson wrote:
> >>
> >>>( Republished under appropriate Subject :-( ).
> >>>
> >>>Hey,
> >>>
> >>>I've been toying with the idea of Modelling my form beans using XML Schema,
> >>>then generating the actual beans using some XML binding tool like Castor (which
> >>>should also generate my validate function). I should also be able to use
> >>>Castor to do RDBMS mapping as well.. (but from a session bean manipulating the
> >>>formbeans for example).
> >>>
> >>>I'm thinking of utilising schema from developments such as RosettaNet, BizTalk
> >>>Frameworks and ebXML - noting that often the info entered into forms could be
> >>>the same message information that might be passed between businesses. (Eg. a
> >>>Purchase Order, etc.).
> >>>
> >>>I'm hoping that the result would: a) help to standardize the business app. b)
> >>>leave it wide open for making use of b-2-b developments such as webServices and
> >>>the above efforts. c) provide automatic form validation (inherent in the
> >>>Schema), d) obviate the hand-coading of formbeans.
> >>>
> >>>Any comments on this approach? Has anyone tried this?
> >>>
> >>>Cheers,
> >>>
> >>>Jon
> >>>
> >>>
> >>>------------------------------------------------------------------------
> >>>
> >>>--
> >>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >>>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>>
> >>--
> >>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> >
> >
> >------------------------------------------------------------------------
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> > Part 1.2
> >
> > Content-Type:
> >
> > text/plain
> >
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building Form Beans from XML Schema?
Posted by Arron Bates <ar...@keyboardmonkey.com>.
Jon,
I'm quite certain the parser has the ability, it just doesn't do it.
It's the generation of the Java code which is stopping it. I would think
you could hack it, so when an object's setter is called automatically
call it's validate() method (which the system creates both, so all you'd
have to hack is when and where) for each object continuing to set all
data (it carries invalid data quite happily, only complains when you ask
it to marshal the document out or validate it) and remember all the
validation errors which were thrown and just pop them into the pile for
Struts. Could be groovy... but it's not an out-of-the-box ability.
I've only had the chance to use the schema side of the matter. We use it
to create the XML documents against the schema, when we have to do
something which requires XML. I don't think my current client is a
particular fan of XML per-se.
Arron.
Jon Ferguson wrote:
>Arron,
>
>Thanks for the hands-on. Shame really.. surely the parser provides this data..
>wonder if there's another way to 'compile' that information into a method.
>
>BTW, have you used Castor's Object-Relational mapping? The second half of the
>equation would be to use that to persist the populated beans from within the
>Action.
>
>Cheers,
>
>Jon
>
>Arron Bates wrote:
>
>>I've tried to do this with Castor generated objects. Problem is though,
>>is that the errors are not fine grained at all.
>>You validate the document by calling the validate() method on the top
>>node, and you get a yes or a no.
>>You can do this for all of the sub objects, but it's just that, you
>>still have to implement the field validation yourself.
>>
>>Naturally you can't play any tricks with the calling of property methods
>>to work around various issues as your objects are locked down to the
>>automation process.
>>
>>Otherwise it's quite excellent.
>>
>>Arron.
>>
>>Jon Ferguson wrote:
>>
>>>( Republished under appropriate Subject :-( ).
>>>
>>>Hey,
>>>
>>>I've been toying with the idea of Modelling my form beans using XML Schema,
>>>then generating the actual beans using some XML binding tool like Castor (which
>>>should also generate my validate function). I should also be able to use
>>>Castor to do RDBMS mapping as well.. (but from a session bean manipulating the
>>>formbeans for example).
>>>
>>>I'm thinking of utilising schema from developments such as RosettaNet, BizTalk
>>>Frameworks and ebXML - noting that often the info entered into forms could be
>>>the same message information that might be passed between businesses. (Eg. a
>>>Purchase Order, etc.).
>>>
>>>I'm hoping that the result would: a) help to standardize the business app. b)
>>>leave it wide open for making use of b-2-b developments such as webServices and
>>>the above efforts. c) provide automatic form validation (inherent in the
>>>Schema), d) obviate the hand-coading of formbeans.
>>>
>>>Any comments on this approach? Has anyone tried this?
>>>
>>>Cheers,
>>>
>>>Jon
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>
>------------------------------------------------------------------------
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> Part 1.2
>
> Content-Type:
>
> text/plain
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building Form Beans from XML Schema?
Posted by Jon Ferguson <fe...@ieee.org>.
Arron,
Thanks for the hands-on. Shame really.. surely the parser provides this data..
wonder if there's another way to 'compile' that information into a method.
BTW, have you used Castor's Object-Relational mapping? The second half of the
equation would be to use that to persist the populated beans from within the
Action.
Cheers,
Jon
Arron Bates wrote:
> I've tried to do this with Castor generated objects. Problem is though,
> is that the errors are not fine grained at all.
> You validate the document by calling the validate() method on the top
> node, and you get a yes or a no.
> You can do this for all of the sub objects, but it's just that, you
> still have to implement the field validation yourself.
>
> Naturally you can't play any tricks with the calling of property methods
> to work around various issues as your objects are locked down to the
> automation process.
>
> Otherwise it's quite excellent.
>
> Arron.
>
> Jon Ferguson wrote:
>
> >( Republished under appropriate Subject :-( ).
> >
> >Hey,
> >
> >I've been toying with the idea of Modelling my form beans using XML Schema,
> >then generating the actual beans using some XML binding tool like Castor (which
> >should also generate my validate function). I should also be able to use
> >Castor to do RDBMS mapping as well.. (but from a session bean manipulating the
> >formbeans for example).
> >
> >I'm thinking of utilising schema from developments such as RosettaNet, BizTalk
> >Frameworks and ebXML - noting that often the info entered into forms could be
> >the same message information that might be passed between businesses. (Eg. a
> >Purchase Order, etc.).
> >
> >I'm hoping that the result would: a) help to standardize the business app. b)
> >leave it wide open for making use of b-2-b developments such as webServices and
> >the above efforts. c) provide automatic form validation (inherent in the
> >Schema), d) obviate the hand-coading of formbeans.
> >
> >Any comments on this approach? Has anyone tried this?
> >
> >Cheers,
> >
> >Jon
> >
> >
> >------------------------------------------------------------------------
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building Form Beans from XML Schema?
Posted by Arron Bates <ar...@keyboardmonkey.com>.
I've tried to do this with Castor generated objects. Problem is though,
is that the errors are not fine grained at all.
You validate the document by calling the validate() method on the top
node, and you get a yes or a no.
You can do this for all of the sub objects, but it's just that, you
still have to implement the field validation yourself.
Naturally you can't play any tricks with the calling of property methods
to work around various issues as your objects are locked down to the
automation process.
Otherwise it's quite excellent.
Arron.
Jon Ferguson wrote:
>( Republished under appropriate Subject :-( ).
>
>Hey,
>
>I've been toying with the idea of Modelling my form beans using XML Schema,
>then generating the actual beans using some XML binding tool like Castor (which
>should also generate my validate function). I should also be able to use
>Castor to do RDBMS mapping as well.. (but from a session bean manipulating the
>formbeans for example).
>
>I'm thinking of utilising schema from developments such as RosettaNet, BizTalk
>Frameworks and ebXML - noting that often the info entered into forms could be
>the same message information that might be passed between businesses. (Eg. a
>Purchase Order, etc.).
>
>I'm hoping that the result would: a) help to standardize the business app. b)
>leave it wide open for making use of b-2-b developments such as webServices and
>the above efforts. c) provide automatic form validation (inherent in the
>Schema), d) obviate the hand-coading of formbeans.
>
>Any comments on this approach? Has anyone tried this?
>
>Cheers,
>
>Jon
>
>
>------------------------------------------------------------------------
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Building Form Beans from XML Schema?
Posted by Jon Ferguson <fe...@ieee.org>.
( Republished under appropriate Subject :-( ).
Hey,
I've been toying with the idea of Modelling my form beans using XML Schema,
then generating the actual beans using some XML binding tool like Castor (which
should also generate my validate function). I should also be able to use
Castor to do RDBMS mapping as well.. (but from a session bean manipulating the
formbeans for example).
I'm thinking of utilising schema from developments such as RosettaNet, BizTalk
Frameworks and ebXML - noting that often the info entered into forms could be
the same message information that might be passed between businesses. (Eg. a
Purchase Order, etc.).
I'm hoping that the result would: a) help to standardize the business app. b)
leave it wide open for making use of b-2-b developments such as webServices and
the above efforts. c) provide automatic form validation (inherent in the
Schema), d) obviate the hand-coading of formbeans.
Any comments on this approach? Has anyone tried this?
Cheers,
Jon
Re: Submission... tag library
Posted by Jon Ferguson <fe...@ieee.org>.
Hey,
I've been toying with the idea of Modelling my form beans using XML Schema,
then generating the actual beans using some XML binding tool like Castor (which
should also generate my validate function). I should also be able to use
Castor to do RDBMS mapping as well.. (but from a session bean manipulating the
formbeans for example).
I'm thinking of utilising schema from developments such as RosettaNet, BizTalk
Frameworks and ebXML - noting that often the info entered into forms could be
the same message information that might be passed between businesses. (Eg. a
Purchase Order, etc.).
I'm hoping that the result would: a) help to standardize the business app. b)
leave it wide open for making use of b-2-b developments such as webServices and
the above efforts. c) provide automatic form validation (inherent in the
Schema), d) obviate the hand-coading of formbeans.
Any comments on this approach? Has anyone tried this?
Cheers,
Jon
Re: Submission... tag library
Posted by Jon Ferguson <fe...@ieee.org>.
Ed,
I'm rather new to Struts and taglibs.. however, this seems like a very useful
taglib project. Table presentation seems to popup everywhere in business app
web development. The easy sorting ais cool... Its pretty easy to think of
several other features: intable editing, expandable rows, etc. that might be
useful. Thanks for your input.
Jon
Ed Hill wrote:
> Hello,
>
> A few weeks ago, I mentioned in the struts-user list a tag library that we
> are developing which at the time I called gui:table... I didn't have the
> source ready to go at the time - but rather then trying to get it perfect in
> isolation, I'll risk the public humiliation and go ahead and make available
> what I have now and try to work with others who are interested in
> helping me polish it up.
>
> Currently, this taglib has a single key tag called "table" that takes a list
> of objects and displays them as a table. It has various features
> (alternating row colors, using a decorator for formatting, sorting,
> pagination, etc...)
>
> My goal over time will be to add other common "high-level" web display
> patterns to the tag library, for example:
>
> - display:table
> - display:tree
> - display:tabs
> - display:inspector
> - etc...
>
> The source to this tag library is available at:
>
> http://edhill.its.uiowa.edu/downloads/display.zip
>
> Examples, showing usage can be found at:
>
> http://edhill.its.uiowa.edu/display-examples/
>
> Currently, documentation is little more then just the examples.
>
> To be honest, my original intention was to donate this taglib to struts if
> there was interest, as we are heavy struts users here at the U of Iowa, and
> I wanted to give back if possible, but there is nothing "struts-specific"
> about the taglib (other then using some struts-like naming conventions for
> attributes), so it is probably more appropriately a candidate for the taglib
> project, and as such, I have been working on getting the build process for
> the tag working in a jakarta-taglib style.
>
> I welcome any and all feedback and advice. If this taglib seems like
> something that would be useful for either struts or taglibs, please let me
> know, and I'll be happy to work with either group to get it put into CVS and
> on a more serious release schedule.
>
> I am currently being presumptuous, and have the taglib living in the
> org.apache.taglibs.display package, but if this doesn't seem like something
> that would be of use to taglibs, I will certainly change the packaging to
> something more appropriate.
>
> Thanks.
>
> -Ed Hill (ed-hill@uiowa.edu)
> Software Developer - Information Technology Services - University of Iowa
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Submission... tag library
Posted by Gervase Gallant <ge...@yahoo.com>.
Ed, in some respects, the implementation you describe
isn't that far from what I have done.
- I have placed the datasource location and have also
provided for the SQL strings to be placed in a
location other than the JSP page. I do this because I
have seen quite a few web developments with SQL-based
pages that were in deep trouble after a database
change. In spite of all this, the specification text
does have to pass everything you would need to connect
to a database and return a data structure. Isn't this
is true for both implementations? If you couldn't I
would wonder how self-contained the tag would be.
- Of course, there is a requirement for a clean -- or
at least as clean as possible -- separation between
the View (the Page) and the Controller/Model. In fact
the Controller/Model needs to be well encapsulated and
self-sufficient.
- However, from my point of view, having worked on
quite a few web developments, it is far more
important that the View has a clean and *simple*
interface. A good example of this are some of the
Coldfusion tags, which provide substantial
functionality from in-line tags. Where a lot of tag
implementations seem to fall apart, at least from my
vantage point, is that they tend to either 1) invent a
whole new scripting language or 2) expose too much
functionality from the API (like giving you a thin
wrapper around a ResultSet or an HTML table.)
What I have tried to do is understand the language of
the Web developer. To my mind, the interface to the
tag succeeds when the consumer (the developer) intuits
it quickly. In my case, I thought providing a visual
example right on the page would be attractive to web
developers. And, as you can see from the examples,
there isn't much beyond the example and setting a
couple of properties.
I'm not saying that my own example works that well.
It's kind of evolving from a more rough-and-tumble
environment. I will have a closer look at your library
to see if it speaks a little more naturally to the Web
developer, particularly the way you attempt to hide
the data retreival.
Anyway thanks. I'll get off my soap box. ;-)
--- Ed Hill <ed...@uiowa.edu> wrote:
> Gervase, thanks for your feedback - I took at look
> at the site you
> referenced, and my comments are inline below...
>
>
> > Ed, This is an intriguing concept. I am still a
> little confused about
> > where the data comes from. You mention a key tag
> called table, but I am
> > not sure how you would use it. For example, how
> would you use it with a
> > JDBC resultset? How do you populate the
> Collections?
>
> The tag design is heavily influenced by struts and
> other MVC design
> patterns. I assume that your Controller (or in a
> typical Model I design,
> your Bean) has taken the actions need to load up a
> list of object's. That
> List would typically contain value objects of some
> type (Users, Cars, Fruit,
> etc...), and then the Controller places the list in
> some scope (page,
> request, session, etc...).
>
> You then tell the table tag where you placed the
> list via the "name"
> attribute. The table tag then iterates over the
> list and uses reflection to
> call various getXXX() methods on the value objects
> in the list to draw each
> row/column.
>
> So there is a clean seperation between the View and
> the Model. The table
> tag is nothing more then a view, it expects some
> other part of your
> application to load and setup the model (the list of
> data).
>
>
> > If you have an opportunity, please check out a
> somewhat similar tag I
> > have developed. It's a little different from your
> in that I was trying
> > to do two things:
> >
> > - allow a non JDBC aware JSP coder to connect a
> ResultSet to an HTML
> > table. I keep a sqlKey property in the tag which
> can either contain the
> > SQL or (better) allow it to be maintained in the
> web.xml
>
> I didn't want the table tag to be JDBC specific. In
> my opinion by doing
> that there was two problems 1) the view knew too
> many details about the
> model and 2) I wanted it to be more generic and work
> with any List of any
> Objects. The reality is that we do our best to
> never expose JDBC specific
> stuff in our JSP pages, we use DAO patterns to
> create value objects, and
> have the DAO isolate the SQL. I would be in the
> camp that doesn't think sql
> based taglibs are a good idea (in most cases - there
> are always exceptions).
>
> Having said that, of course the drawback is that
> currently if you have just
> a ResultSet, you can't currently just pass that onto
> the table. I'm sure
> down the road that will be functionality that would
> make the tag appeal to
> more people.
>
>
> > - allow the JSP person to place an example table
> between the tag start
> > and stop. If the table consists of a header and a
> data row, the tag
> > figures out the formatting from the example. In
> this way, the JSP
> > developer doesn't need extensive Java or JDBC
> knowledge.
>
> I didn't go this route, instead I opted for
> stylesheets, and standard table
> attributes to change the look and feel of the table.
> I will certainly grant
> you that this approach is probably more restrictive
> then yours, but when I
> designed it I was trying to get all of our tables to
> looks basically the
> same through out our applications
>
> >
> >
> > Gervase Gallant
>
>
> -Ed Hill (ed-hill@uiowa.edu)
> Software Developer - Information Technology Services
> - University of Iowa
>
>
> >
> >
> > --- Ed Hill <ed...@uiowa.edu> wrote:
> > > Hello,
> > >
> > > A few weeks ago, I mentioned in the struts-user
> list
> > > a tag library that we
> > > are developing which at the time I called
> > > gui:table... I didn't have the
> > > source ready to go at the time - but rather then
> > > trying to get it perfect in
> > > isolation, I'll risk the public humiliation and
> go
> > > ahead and make available
> > > what I have now and try to work with others who
> are
> > > interested in
> > > helping me polish it up.
> > >
> > > Currently, this taglib has a single key tag
> called
> > > "table" that takes a list
> > > of objects and displays them as a table. It has
> > > various features
> > > (alternating row colors, using a decorator for
> > > formatting, sorting,
> > > pagination, etc...)
> > >
> > > My goal over time will be to add other common
> > > "high-level" web display
> > > patterns to the tag library, for example:
> > >
> > > - display:table
> > > - display:tree
> > > - display:tabs
> > > - display:inspector
> > > - etc...
> > >
> > > The source to this tag library is available at:
> > >
> > >
> > >
> http://edhill.its.uiowa.edu/downloads/display.zip
> > >
> > > Examples, showing usage can be found at:
> > >
> > >
> http://edhill.its.uiowa.edu/display-examples/
> > >
> > > Currently, documentation is little more then
> just
> > > the examples.
> > >
> > > To be honest, my original intention was to
> donate
> > > this taglib to struts if
> > > there was interest, as we are heavy struts users
> > > here at the U of Iowa, and
> > > I wanted to give back if possible, but there is
> > > nothing "struts-specific"
> > > about the taglib (other then using some
> struts-like
> > > naming conventions for
> > > attributes), so it is probably more
> appropriately a
> > > candidate for the taglib
> > > project, and as such, I have been working on
> getting
> > > the build process for
> > > the tag working in a jakarta-taglib style.
> > >
> > > I welcome any and all feedback and advice. If
> this
> > > taglib seems like
> > > something that would be useful for either struts
> or
> > > taglibs, please let me
> > > know, and I'll be happy to work with either
> group to
> > > get it put into CVS and
> > > on a more serious release schedule.
> > >
> > > I am currently being presumptuous, and have the
> > > taglib living in the
> > > org.apache.taglibs.display package, but if this
> > > doesn't seem like something
> > > that would be of use to taglibs, I will
> certainly
> > > change the packaging to
> > > something more appropriate.
> > >
> > > Thanks.
>
=== message truncated ===
=====
Gervase Gallant
Please add gervasegallant@yahoo.com to your address book.
Check out my web site: http://www.javazoid.com
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Submission... tag library
Posted by Ed Hill <ed...@uiowa.edu>.
Gervase, thanks for your feedback - I took at look at the site you
referenced, and my comments are inline below...
> Ed, This is an intriguing concept. I am still a little confused about
> where the data comes from. You mention a key tag called table, but I am
> not sure how you would use it. For example, how would you use it with a
> JDBC resultset? How do you populate the Collections?
The tag design is heavily influenced by struts and other MVC design
patterns. I assume that your Controller (or in a typical Model I design,
your Bean) has taken the actions need to load up a list of object's. That
List would typically contain value objects of some type (Users, Cars, Fruit,
etc...), and then the Controller places the list in some scope (page,
request, session, etc...).
You then tell the table tag where you placed the list via the "name"
attribute. The table tag then iterates over the list and uses reflection to
call various getXXX() methods on the value objects in the list to draw each
row/column.
So there is a clean seperation between the View and the Model. The table
tag is nothing more then a view, it expects some other part of your
application to load and setup the model (the list of data).
> If you have an opportunity, please check out a somewhat similar tag I
> have developed. It's a little different from your in that I was trying
> to do two things:
>
> - allow a non JDBC aware JSP coder to connect a ResultSet to an HTML
> table. I keep a sqlKey property in the tag which can either contain the
> SQL or (better) allow it to be maintained in the web.xml
I didn't want the table tag to be JDBC specific. In my opinion by doing
that there was two problems 1) the view knew too many details about the
model and 2) I wanted it to be more generic and work with any List of any
Objects. The reality is that we do our best to never expose JDBC specific
stuff in our JSP pages, we use DAO patterns to create value objects, and
have the DAO isolate the SQL. I would be in the camp that doesn't think sql
based taglibs are a good idea (in most cases - there are always exceptions).
Having said that, of course the drawback is that currently if you have just
a ResultSet, you can't currently just pass that onto the table. I'm sure
down the road that will be functionality that would make the tag appeal to
more people.
> - allow the JSP person to place an example table between the tag start
> and stop. If the table consists of a header and a data row, the tag
> figures out the formatting from the example. In this way, the JSP
> developer doesn't need extensive Java or JDBC knowledge.
I didn't go this route, instead I opted for stylesheets, and standard table
attributes to change the look and feel of the table. I will certainly grant
you that this approach is probably more restrictive then yours, but when I
designed it I was trying to get all of our tables to looks basically the
same through out our applications
>
>
> Gervase Gallant
-Ed Hill (ed-hill@uiowa.edu)
Software Developer - Information Technology Services - University of Iowa
>
>
> --- Ed Hill <ed...@uiowa.edu> wrote:
> > Hello,
> >
> > A few weeks ago, I mentioned in the struts-user list
> > a tag library that we
> > are developing which at the time I called
> > gui:table... I didn't have the
> > source ready to go at the time - but rather then
> > trying to get it perfect in
> > isolation, I'll risk the public humiliation and go
> > ahead and make available
> > what I have now and try to work with others who are
> > interested in
> > helping me polish it up.
> >
> > Currently, this taglib has a single key tag called
> > "table" that takes a list
> > of objects and displays them as a table. It has
> > various features
> > (alternating row colors, using a decorator for
> > formatting, sorting,
> > pagination, etc...)
> >
> > My goal over time will be to add other common
> > "high-level" web display
> > patterns to the tag library, for example:
> >
> > - display:table
> > - display:tree
> > - display:tabs
> > - display:inspector
> > - etc...
> >
> > The source to this tag library is available at:
> >
> >
> > http://edhill.its.uiowa.edu/downloads/display.zip
> >
> > Examples, showing usage can be found at:
> >
> > http://edhill.its.uiowa.edu/display-examples/
> >
> > Currently, documentation is little more then just
> > the examples.
> >
> > To be honest, my original intention was to donate
> > this taglib to struts if
> > there was interest, as we are heavy struts users
> > here at the U of Iowa, and
> > I wanted to give back if possible, but there is
> > nothing "struts-specific"
> > about the taglib (other then using some struts-like
> > naming conventions for
> > attributes), so it is probably more appropriately a
> > candidate for the taglib
> > project, and as such, I have been working on getting
> > the build process for
> > the tag working in a jakarta-taglib style.
> >
> > I welcome any and all feedback and advice. If this
> > taglib seems like
> > something that would be useful for either struts or
> > taglibs, please let me
> > know, and I'll be happy to work with either group to
> > get it put into CVS and
> > on a more serious release schedule.
> >
> > I am currently being presumptuous, and have the
> > taglib living in the
> > org.apache.taglibs.display package, but if this
> > doesn't seem like something
> > that would be of use to taglibs, I will certainly
> > change the packaging to
> > something more appropriate.
> >
> > Thanks.
> >
> > -Ed Hill (ed-hill@uiowa.edu)
> > Software Developer - Information Technology Services
> > - University of Iowa
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> =====
> Gervase Gallant
> Please add gervasegallant@yahoo.com to your address book.
> Check out my web site: http://www.javazoid.com
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Submission... tag library
Posted by Gervase Gallant <ge...@yahoo.com>.
Ed, This is an intriguing concept. I am still a little
confused about where the data comes from. You mention
a key tag called table, but I am not sure how you
would use it. For example, how would you use it with a
JDBC resultset? How do you populate the Collections?
>From looking at your code, the application of HTML
seems straightforward enough.
If you have an opportunity, please check out a
somewhat similar tag I have developed. It's a little
different from your in that I was trying to do two
things:
- allow a non JDBC aware JSP coder to connect a
ResultSet to an HTML table. I keep a sqlKey property
in the tag which can either contain the SQL or
(better) allow it to be maintained in the web.xml
- allow the JSP person to place an example table
between the tag start and stop. If the table consists
of a header and a data row, the tag figures out the
formatting from the example. In this way, the JSP
developer doesn't need extensive Java or JDBC
knowledge.
Please check it out at:
http://www.javazoid.com/reportwriter.html
Gervase Gallant
--- Ed Hill <ed...@uiowa.edu> wrote:
> Hello,
>
> A few weeks ago, I mentioned in the struts-user list
> a tag library that we
> are developing which at the time I called
> gui:table... I didn't have the
> source ready to go at the time - but rather then
> trying to get it perfect in
> isolation, I'll risk the public humiliation and go
> ahead and make available
> what I have now and try to work with others who are
> interested in
> helping me polish it up.
>
> Currently, this taglib has a single key tag called
> "table" that takes a list
> of objects and displays them as a table. It has
> various features
> (alternating row colors, using a decorator for
> formatting, sorting,
> pagination, etc...)
>
> My goal over time will be to add other common
> "high-level" web display
> patterns to the tag library, for example:
>
> - display:table
> - display:tree
> - display:tabs
> - display:inspector
> - etc...
>
> The source to this tag library is available at:
>
>
> http://edhill.its.uiowa.edu/downloads/display.zip
>
> Examples, showing usage can be found at:
>
> http://edhill.its.uiowa.edu/display-examples/
>
> Currently, documentation is little more then just
> the examples.
>
> To be honest, my original intention was to donate
> this taglib to struts if
> there was interest, as we are heavy struts users
> here at the U of Iowa, and
> I wanted to give back if possible, but there is
> nothing "struts-specific"
> about the taglib (other then using some struts-like
> naming conventions for
> attributes), so it is probably more appropriately a
> candidate for the taglib
> project, and as such, I have been working on getting
> the build process for
> the tag working in a jakarta-taglib style.
>
> I welcome any and all feedback and advice. If this
> taglib seems like
> something that would be useful for either struts or
> taglibs, please let me
> know, and I'll be happy to work with either group to
> get it put into CVS and
> on a more serious release schedule.
>
> I am currently being presumptuous, and have the
> taglib living in the
> org.apache.taglibs.display package, but if this
> doesn't seem like something
> that would be of use to taglibs, I will certainly
> change the packaging to
> something more appropriate.
>
> Thanks.
>
> -Ed Hill (ed-hill@uiowa.edu)
> Software Developer - Information Technology Services
> - University of Iowa
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
Gervase Gallant
Please add gervasegallant@yahoo.com to your address book.
Check out my web site: http://www.javazoid.com
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>