Please see inline ....
Werner
Uday Kari wrote:
> Actually, I stand corrected. Indeed, castor classes meet java bean
> standards.
>
> But there are still two (2) "problems" that would need to be solved
> (or "extensions" similar to what the java bean standard has):
>
> 1. Nested properties. Say your highest level castor object in turn
> is made up of several other castor generated objects which in turn
> have others and so on. The JSP guys have a solution to this. They
> created the expression language in version 2.4 of the standard. We
> perhaps need to consider something equivalent in Castor. Basically
> we would want to map any random request parameter to any property of
> the child element. This is, perhaps, best achieved by automatically
> generating wrapper class for the highest castor object which has the
> required getter, setter methods to return/accept a string argument
> for properties of all its child elements including nested ones.
>
> 2. String input. Note that HTTP request parameters are always
> String, while beans themselves may have any exotic java object as
> properties. This requires one to typically write a converter (at
> least that is the only way I know) to capture the string object and
> convert it into BigDecimal etc. And we have to do this ad nauseum
> for every parameter in every one of the numerous classes generated by
> castor ( in a large project). Instead if there was a way to generate
> a convenience wrapper code for castor classes specifically for use as
> a java bean that is setting its properties >from (pure string)
> request parameters it would be great.
There's always the option to extend the XML code generator so that
additional methods get generated, incl. e.g. a new
public void setProperty(String value) { .. }
method for every property to be found within a class generated. Whilst
this is not really high on my list of priorities (as it clearyl is not a
core feature of a class generator for XML schemas), I'd be more than
willing to assist you in coming up with additional code to implement
such a feature and get it integrated into the code base.
If such an approach would be acceptable to you, I'd like to hear you
views on how to approach this.
>
> To generalize then, if there is some guidance on how one may write
> code to *generate* wrappers for Castor classes by leveraging Castor
> code itself, may be folks will go ahead and do it for various
> projects and keep them scalable.
>
> Lot of work, I know...
>
>
> -----Original Message----- From: Werner Guttmann
> [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007
> 10:19 PM To: [email protected] Subject: AW: [castor-user] Java
> Bean Wrapper for Castor Classes
>
> As the Java classes generated by the XML code generator (aka source
> generator) are JavaBeans compliant, the answer is ... well, no. I
> don't see a reason as to why a JavaBeans wrapper should be generated
> when the classes in question are JavaBeans themselves.
>
>
> Werner
>
> ________________________________________ Von: Uday Kari
> [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 23. März 2007 02:03 An:
> [email protected] Betreff: [castor-user] Java Bean Wrapper for
> Castor Classes
>
> Another old concern of mine: Is there a way to generate Java Bean
> (wrappers) for java classes that Castor generates from XSD? If so,
> this would be very useful in writing "marshalling servlets".
> Basically, we can use this to marshal XML from request parameters of
> a jsp. This would be very useful for my project except that I am
> somewhat lazy and reluctant to write the bean wrappers myself (which
> will all have to change for any change in XSD). Catch 22 is that I
> cannot use castor classes directly as beans since castor itself is
> using the default constructors. Hope I am making sense...Thanks.
>
> ________________________________________ From: Uday Kari Sent:
> Thursday, August 31, 2006 11:52 AM To: 'Arnaud Blandin';
> [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Java Bean
> Wrapper for Castor Classes
>
> Arnaud: Thanks for your response. Look forward to hearing from
> Werner and/or Keith. At this stage, all I have is raw
> source...anything that explains the inner working a little better
> would be useful. As I said, I would be honored to contribute code,
> but need some help getting started and perhaps be more effective. I
> would much rather prefer this type of team work (or endorsement or
> blessing!), rather than attempting to do an extension that is
> completely homegrown (especially in production). Much Regards, Uday
>
>
> ________________________________________ From: Arnaud Blandin
> [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 11:18 AM
> To: Uday Kari; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject:
> RE: Java Bean Wrapper for Castor Classes
>
> Dear Uday,
>
> It seems to me that you would like to take a look at the source
> generator. Maybe you could expand the binding file to add the proper
> functionality. Unfortunately I cannot help you more at this stage as
> I am not active anymore on the project. I am sure Werner or Keith can
> guide you.
>
> Best Regards,
>
> Arnaud
>
> ________________________________________ From: Uday Kari
> [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 5:55 AM To:
> [EMAIL PROTECTED] Cc: Arnaud Blandin; [EMAIL PROTECTED] Subject:
> Java Bean Wrapper for Castor Classes Keith, Arnaud, Werner:
>
> Is there a way to generate Java Bean (wrappers) for java classes that
> Castor generates from XSD?
>
> I am unable to use Castor generated classes directly as java beans
> since the required default constructor is used for all sorts of the
> namespace related housekeeping. Therefore, I am unable to set member
> variable directly as bean properties from, say, HTTPrequest. Also,
> since Castor classes generate properties such as BigDecimal, I would
> like to handle converting string parameters from request before
> setting properties. Therefore, the best strategy was to create java
> bean wrappers to:
>
> A. Appropriately convert request parameters to Castor generated data
> types. B. Pass through these parameters from the java bean wrapper to
> the corresponding Castor "twin" class. C. When marshalling and
> unmarshalling, the presentation layer thinks it is dealing with the
> java bean, but it is the Castor implementation layer underneath that
> handles everything.
>
> I have tested the idea successfully, by hand-coding the required bean
> wrappers. However, when dealing with complex XSD as follows:
>
> http://www.pdc.org/pride/xmlschema/ptwc.xsd ...
>
> I really wish I could generate these bean wrappers "automagically"
> just like Castor generates classes from XSD, simply because since
> there are so many (140 classes) of them !!
>
> If you could give me some tips on how exactly you conduct the
> transformation of XSD into Castor classes (through architecture
> documents, dataflow diagrams), I would be glad to contribute some
> code to your project that generates these java bean wrappers for
> Castor classes. I am just beginning to decipher the code, but don't
> have much documentation or forums to work with. I am sure there are
> other developers who could use this.
>
> Alternatively, you could give me some tips on why I should not be
> doing this (i.e. can I somehow create one "master class" to
> marshal/unmarshall any of its 140 child objects?).
>
> Much Regards (and keep up the good, no excellent, work!)
>
> Uday S. Kari Software Development Lead PACIFIC DISASTER CENTER 1305 N
> Holopono St, Suite 2 Kihei, HI 96753 (808) 891-7942 www.pdc.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
