subject:"Struts 2.0 Discussion Forum"

Quoting [EMAIL PROTECTED]:

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 19, 2003 11:00 AM
> To: Struts Developers List
> Subject: RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
> 
> Quoting [EMAIL PROTECTED]:
> 
> > We have a solution for dynamic page content that is component based.
> I
> > wouldn't say that it stands up to JSF but it's similar in concept.
> The
> > content of the page is defined using xml metadata.
> >
> > However, I suppose that you could argue, why not use JSF?  I would be
> > interested in hearing what advantage you would have using struts with
> JSF
> > when JSF handles both the view layer and controller?
> >
> 
> >>Fair question.  In the long run, we (Struts) are definitely going to
> >>have to "compete" with this combination.
> 
> >>The easiest way is to focus on features that are not present in JSF --
> >>one approach would be to build on top of the JSF controller
> >>infrastructure.
> 
> >>Besides the UI components, there are some very useful foundational
> >>things there (such as managed beans, which generalize the way that
> >>Struts auto-creates form beans on demand, fine-grained navigation
> rules, >>and the ability to programmatically evaluate EL-ish
> expressions, >>including the ability to plug in new evaluators for the
> "." operator) >>that would be nice to use in a controller tier.
> 
> I have been struggling to correlate the notion of a struts formbean with a
> jsf UI component.  Under struts, a single action can be associated with
> only one formbean.  If the form is a composition of many components,
> should each component have its own "formbean"?  It sounds as each jsf
> component would pull values on its own behalf from the request parameters
> thru a converter.
> 

In Struts terminology, a JSF UI component relates more to an individual form
bean property than it does to the form bean itself.  However, the type
conversion mechanism *is* built in to the UI components in JSF, so you can have
your "form bean" using native data types without the penalties you'd suffer
doing this with the standard Struts tags.

> To achieve visual component reuse, it sounds like jsf introduces the
> notion of a client id.  We have used an underscore as our component
> delimiter because the beanutils handles the "." for nested components.
> 

Components do have identifiers that are composed based on the "naming container"
components (such as UIForm).  The composition delimiter that JSF chose is the
":" character, primarily to avoid confusion over what "." means in JavaScript.

> It seems that if you had a single form bean to map to a graph of UI
> components, the form bean might get kind of ugly.
> 
>
>  name="aboutForm_BorderLayout_west_dateWidget_selDate"
>type="java.lang.String"/>
>  
name="aboutForm_BorderLayout_center_calendarWidget_GridLayout_B0_yearWidget_year"
>  type="java.lang.String"/>
> 
> 
name="aboutForm_BorderLayout_center_calendarWidget_GridLayout_A0_monthWidget_month"
>  type="java.lang.String"/>
> 
>   
> 
> It would be nice if the behavior of the formbean to an aciton could also
> be associated with a UI component.
> 

If you use the struts-faces integration library, you don't need to change
anything at all about your form bean definitions -- you still use the property
names.  The page author, though, has to prefix the value reference expressions
on each property with the name of the corresponding form bean (because JSF does
not constrain you to a single form bean).

> It sounds like the struts chains will be similar to the jsf component
> tree?  Could a chain command be associated with a individual formbean and
> a command be corrolated to a UI component?
> 

Hmm, I'm not sure I see that connection.  I see the chain used (inside Struts)
to compose the stuff that happens after a form has been submitted -- versus the
hard coded logic inside RequestProcessor -- but you could certainly attach a
different chain to each of the different submit buttons on a given form, for
example.

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Craig R. McClanahan wrote:
"Workflow" is one of those wonderful words that means different things to
different people :-).  It makes sense to think about webapp frameworks wanting
to deal with workflows for individual conversations (think of managing a wizard
dialog, which is a very common use case) as well as the higher level stuff with
orchestration and all of that.
We might want to seriously consider offering LivingLogic's workflow as a 
standard option, like Validator and Tiles. I'm still ambivalent, but 
it's the oldest and most popular offering. It would at least get us
started.

http://www.livinglogic.de/Struts/

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread gvanmatre

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Friday, December 19, 2003 11:00 AM
To: Struts Developers List
Subject: RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting [EMAIL PROTECTED]:

> We have a solution for dynamic page content that is component based.
I
> wouldn't say that it stands up to JSF but it's similar in concept.
The
> content of the page is defined using xml metadata.
>
> However, I suppose that you could argue, why not use JSF?  I would be
> interested in hearing what advantage you would have using struts with
JSF
> when JSF handles both the view layer and controller?
>

>>Fair question.  In the long run, we (Struts) are definitely going to
>>have to "compete" with this combination.

>>The easiest way is to focus on features that are not present in JSF --
>>one approach would be to build on top of the JSF controller
>>infrastructure.

>>Besides the UI components, there are some very useful foundational
>>things there (such as managed beans, which generalize the way that
>>Struts auto-creates form beans on demand, fine-grained navigation
rules, >>and the ability to programmatically evaluate EL-ish
expressions, >>including the ability to plug in new evaluators for the
"." operator) >>that would be nice to use in a controller tier.

I have been struggling to correlate the notion of a struts formbean with a
jsf UI component.  Under struts, a single action can be associated with
only one formbean.  If the form is a composition of many components,
should each component have its own "formbean"?  It sounds as each jsf
component would pull values on its own behalf from the request parameters
thru a converter.

To achieve visual component reuse, it sounds like jsf introduces the
notion of a client id.  We have used an underscore as our component
delimiter because the beanutils handles the "." for nested components.

It seems that if you had a single form bean to map to a graph of UI
components, the form bean might get kind of ugly.

It would be nice if the behavior of the formbean to an aciton could also
be associated with a UI component.

It sounds like the struts chains will be similar to the jsf component
tree?  Could a chain command be associated with a individual formbean and
a command be corrolated to a UI component?

> Consider the following DTD and XML snippet:
>
>
> 
>displayElementId CDATA #REQUIRED
>   type %DisplayElementType; #IMPLIED
>   jspName CDATA #IMPLIED
>   extends CDATA #IMPLIED
>   modelClassname CDATA #IMPLIED
>   roles CDATA #IMPLIED
>   useContainerNaming %Boolean; #IMPLIED
> >
>
> 
>name CDATA #REQUIRED
>   value CDATA #REQUIRED
> >
>
> 
>attName CDATA #IMPLIED
>   displayName CDATA #IMPLIED
>   displayElementId CDATA #REQUIRED
>   requiredField %Boolean; #IMPLIED
>   sequence CDATA #REQUIRED
>   roles CDATA #IMPLIED
>   useContainerNaming %Boolean; #IMPLIED
> >
>
> This is an example of building a change password page.  The
> "changePasswdForm" is the root "component".
>
> 
>
> 
> 
>   displayName="message.required.legend" sequence="99"/>
> 
>
>
> 
>
> 
>
>   
>   
>
>   
>   
> 
>   
>
>   
> 
>   
>
>   
>  
>   
>
>   
>  
>   
>
> 
>
>
>
> 
> 
>
>   displayName="cuPassword.display" sequence="1"
>   requiredField="true">
>   
>   
>   
>
>
>   displayName="retypePassword.display" sequence="2"
>   requiredField="true">
>
>   
>   
>   
>
>
> 
>

Roll your own templating languages are certainly possible, but it's also
nice to
leverage prior art when you can.

A completely different way to consider using JSF would be to build a
RenderKit
that took input like this and generated the corresponding HTML (or
whatever)
markup, starting from the exact same components as the standard HTML
RenderKit.
 In the JSF release, there is the very beginnings of an example how this
can be
done, which uses XUL as the input templating language.  Fleshing
something like
this out could leverage the fact that Mozilla has already popularized
this as a
technology for defining page layout, as well as some amount of
interactivity.

Craig

- To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Mete Kural <[EMAIL PROTECTED]>:

> >If we do things right, IMHO workflow support system(s) should be a layer on
> top
> >of the foundational request handling capability, so you can use it if you
> need
> >it but it doesn't get in the way if you don't.
> 
> I think I agree here. Isn't workflow something that the business tier
> implements in a properly designed application? Since a workflow is based on
> business rules specific to an organization, why should the webapp front-end
> deal with workflow issues, and not leave it up to the business tier?
> 

"Workflow" is one of those wonderful words that means different things to
different people :-).  It makes sense to think about webapp frameworks wanting
to deal with workflows for individual conversations (think of managing a wizard
dialog, which is a very common use case) as well as the higher level stuff with
orchestration and all of that.


> Thanks,
> Mete

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Mete Kural <[EMAIL PROTECTED]>:

> Hi Craig,
> 
> >A completely different way to consider using JSF would be to build a
> RenderKit
> >that took input like this and generated the corresponding HTML (or
> whatever)
> >markup, starting from the exact same components as the standard HTML
> RenderKit.
> > In the JSF release, there is the very beginnings of an example how this can
> be
> >done, which uses XUL as the input templating language.  Fleshing something
> like
> >this out could leverage the fact that Mozilla has already popularized this
> as a
> >technology for defining page layout, as well as some amount of
> interactivity.
> 
> I have a question here. I've been thinking of ways of how JSF and XSLT could
> be leveraged together, with or without leveraging JSP. Let's say we have an
> application where the Action classes make lots of calls to SOAP services and
> sometimes receive fairly large XML documents. In the case of large XML
> responses, converting the XML to POJOs may turn out to be unnecessary
> processing, where as you can simply do an XSLT transformation over the XML
> response to generate the final markup output. So what would be an efficient
> way to leverage both JSF and XSLT here? Could this be a good strategy:
> 
> "Implement a RenderKit and JSF components that take XML documents as the
> business object input (instead of JavaBeans, Maps, etc.) and uses XSLT to
> generate the device-specific markup output. Then if you are using JSP as the
> templating system, implement a JSP taglib to call these components. If you're
> using another templating engine, write a tag library specific to that
> templating system and call your components."
> 

One of the interesting things about JSF is that it's a two level API --
components and renderers have a JavaBeans-ish API to be used directly (or from
the templating environment's renderers), and you can build a JSP custom tag
around them to get access from the JSP layer.  For example, doing something
like JSTL's  tag in JSF would be as simple as:

* No new component needed ... leverage the "generic attributes"
  capability of the standard UIOutput component class.  Or, if
  you really want, you can create a component class if you like
  exposing everything as JavaBeans properties.

* Create a new XsltRenderer that uses the "value" property
  of the UIOutput component to point at the XML data to be
  transformed, and (perhaps) an "xslt" attribute to point at
  the stylesheet.  (I'd suggest making the syntax and semantics
  as close as possible to  for maximum familiarity),
  and used JAXP APIs to perform the transformation, followed
  by writing the output to the response.

* Create a JSF component tag that marries the two together
  (about 30 lines of code) and utilizes the Java-level APIs
  underneath.

Hmm, that's about 30 minutes of effort, and you get an XSLT transformation
component that can be used in JSP or any other templating environment supported
by your JSF RenderKit.  I should have some time to play with stuff like this
next week, when Sun shuts down for the Christmas break.

> >Craig
> 
> Mete
> 

Craig

PS:  Of course, if you're using JSP as your rendering technology, nothing stops
you from using tags like  in the same page as your components, if
you want.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread Mete Kural

>If we do things right, IMHO workflow support system(s) should be a layer on top
>of the foundational request handling capability, so you can use it if you need
>it but it doesn't get in the way if you don't.

I think I agree here. Isn't workflow something that the business tier implements in a 
properly designed application? Since a workflow is based on business rules specific to 
an organization, why should the webapp front-end deal with workflow issues, and not 
leave it up to the business tier?

Thanks,
Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread Mete Kural

Hi Craig,

>A completely different way to consider using JSF would be to build a RenderKit
>that took input like this and generated the corresponding HTML (or whatever)
>markup, starting from the exact same components as the standard HTML RenderKit.
> In the JSF release, there is the very beginnings of an example how this can be
>done, which uses XUL as the input templating language.  Fleshing something like
>this out could leverage the fact that Mozilla has already popularized this as a
>technology for defining page layout, as well as some amount of interactivity.

I have a question here. I've been thinking of ways of how JSF and XSLT could be 
leveraged together, with or without leveraging JSP. Let's say we have an application 
where the Action classes make lots of calls to SOAP services and sometimes receive 
fairly large XML documents. In the case of large XML responses, converting the XML to 
POJOs may turn out to be unnecessary processing, where as you can simply do an XSLT 
transformation over the XML response to generate the final markup output. So what 
would be an efficient way to leverage both JSF and XSLT here? Could this be a good 
strategy:

"Implement a RenderKit and JSF components that take XML documents as the business 
object input (instead of JavaBeans, Maps, etc.) and uses XSLT to generate the 
device-specific markup output. Then if you are using JSP as the templating system, 
implement a JSP taglib to call these components. If you're using another templating 
engine, write a tag library specific to that templating system and call your 
components."

>Craig

Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting "n. alex rupp" <[EMAIL PROTECTED]>:

> What about including a Dynamic rules-based workflow engine?  One like
> Drools?
> This is great because it abstracts a lot of the operational control of the
> application into the realm of the business person.  It seems to me that IoC
> is a
> good start, but following up with a business rules based control system
> would
> greatly benefit a lot of companies.  When the rules of the business changed,
> they could alter the operation of the web application without having to push
> their changes and requirements through the developers.
> 

If we do things right, IMHO workflow support system(s) should be a layer on top
of the foundational request handling capability, so you can use it if you need
it but it doesn't get in the way if you don't.  A rules-based environment is
certainly one way to do it; so is scripted dialongs with some sort of
continuations (like the Cocoon folks are playing with).

> This implies creating management tools, which breaches the question: can we
> put
> JMX management hooks into Struts 2.0 so that all the different components
> and
> their configurations can be managed at runtime?
> 

Certainly possible, but if you've come from an environment of creating
containers and having full control over class loaders and security managers,
you're going to find yourself somewhat frustrated by the limitations of what
you can do portably *inside* a webapp :-).

> --
> N. Alex  Rupp ([EMAIL PROTECTED])
> 

Craig

PS:  Alex, it's interesting to note that a lot of the webapp framework folks are
all focusing on decomposing their request processors at the same time.  The
idea we've been playing with that is similar to Shocks is the commons-chain
package (in the Jakarta Commons sandbox), and an experimental implementation of
the Struts 1.1 request processor in the "contrib/struts-chain" source
directory.  One thing I'd recommend you think about is decoupling your
execute() API from the servlet request and response objects, so you can reuse
the basic idea inside the business tier as well.


> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting [EMAIL PROTECTED]:

> We have a solution for dynamic page content that is component based.  I
> wouldnt say that it stands up to JSF but its similar in concept.  The
> content of the page is defined using xml metadata.
> 
> However, I suppose that you could argue, why not use JSF?  I would be
> interested in hearing what advantage you would have using struts with JSF
> when JSF handles both the view layer and controller?
> 

Fair question.  In the long run, we (Struts) are definitely going to have to
"compete" with this combination.

The easiest way is to focus on features that are not present in JSF -- one
approach would be to build on top of the JSF controller infrastructure. 
Besides the UI components, there are some very useful foundational things there
(such as managed beans, which generalize the way that Struts auto-creates form
beans on demand, fine-grained navigation rules, and the ability to
programmatically evaluate EL-ish expressions, including the ability to plug in
new evaluators for the "." operator) that would be nice to use in a controller
tier.

> Consider the following DTD and XML snippet:
> 
> 
> 
>displayElementId CDATA #REQUIRED
>   type %DisplayElementType; #IMPLIED
>   jspName CDATA #IMPLIED
>   extends CDATA #IMPLIED
>   modelClassname CDATA #IMPLIED
>   roles CDATA #IMPLIED
>   useContainerNaming %Boolean; #IMPLIED
> >
> 
> 
>name CDATA #REQUIRED
>   value CDATA #REQUIRED
> >
> 
> 
>attName CDATA #IMPLIED
>   displayName CDATA #IMPLIED
>   displayElementId CDATA #REQUIRED
>   requiredField %Boolean; #IMPLIED
>   sequence CDATA #REQUIRED
>   roles CDATA #IMPLIED
>   useContainerNaming %Boolean; #IMPLIED
> >
> 
> This is an example of building a change password page.  The
> "changePasswdForm" is the root "component".
> 
> 
> 
> 
> 
>   displayName="message.required.legend" sequence="99"/>
> 
> 
> 
> 
> 
> 
> 
>   
>   
> 
>   
>   
> 
>   
> 
>   
> 
>   
> 
>   
>  
>   
> 
>   
>  
>   
> 
> 
> 
> 
> 
> 
> 
> 
>   displayName="cuPassword.display" sequence="1"
>   requiredField="true">
>   
>   
>   
>
> 
>   displayName="retypePassword.display" sequence="2"
>   requiredField="true">
> 
>   
>   
>   
>
> 
> 
> 

Roll your own templating languages are certainly possible, but it's also nice to
leverage prior art when you can.

A completely different way to consider using JSF would be to build a RenderKit
that took input like this and generated the corresponding HTML (or whatever)
markup, starting from the exact same components as the standard HTML RenderKit.
 In the JSF release, there is the very beginnings of an example how this can be
done, which uses XUL as the input templating language.  Fleshing something like
this out could leverage the fact that Mozilla has already popularized this as a
technology for defining page layout, as well as some amount of interactivity.

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread n. alex rupp

What about including a Dynamic rules-based workflow engine?  One like Drools?
This is great because it abstracts a lot of the operational control of the
application into the realm of the business person.  It seems to me that IoC is a
good start, but following up with a business rules based control system would
greatly benefit a lot of companies.  When the rules of the business changed,
they could alter the operation of the web application without having to push
their changes and requirements through the developers.

This implies creating management tools, which breaches the question: can we put
JMX management hooks into Struts 2.0 so that all the different components and
their configurations can be managed at runtime?

--
N. Alex  Rupp ([EMAIL PROTECTED])


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Joe Germuska <[EMAIL PROTECTED]>:

> 
> As for PicoContainer, if someone could just show me how you write an 
> external configuration file that wires together objects through their 
> constructors, I might buy it, but it just doesn't seem to match up. 
> As soon as you had one new collaborator that you hadn't planned for, 
> you'd have to rewrite some java code somewhere, wouldn't you?
> 

My understanding is that configuration files are outside the scope of Pico
itself, but that's where things like NanoContainer come into play -- several
implementations of using Pico (including configuration support).

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting David Graham <[EMAIL PROTECTED]>:

> 
> If we want IoC inside of Struts we should look at something lighter weight
> like HiveMind.  I'd also like some focused concrete examples of how IoC
> would benefit Struts internals before we decide to go that route.  
> 

Presuming the IP issues around Hivemind get worked out, using it for our IoC
configuration needs would be pretty attractive -- among other things, it'll
already be Apache code, and we'll benefit from the cross fertilization of its
use in Tapestry.

> David

Craig

PS:  By the way, I met Howard Lewis Ship (and his wife Suzy) at ApacheCon.  We
had a great time seeing the StarTrek Experience (in Las Vegas) together,
achieving our goal of getting some of the cast members to laugh with us instead
of following their script when the three of us were the entire audience for the
last show of that evening ... very enjoyable!


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Yes, Spring is nice becuse not only does it provide a consistent
factory-based implementation, but the code isn't dependent on Spring and
could be replaced with some other IoC mechanism down the road if desired.

Don

On Fri, 19 Dec 2003, Ted Husted wrote:

> Don Brown wrote:
> > I see Spring as helping Struts be better structure its internal
> > components, specifically using a BeanFactory implementation.  It would not
> > replace struts-config in any way or even be exposed directly the a Struts
> > application.  The struts-chain request processor implementation makes it
> > easy for Struts apps to plug in IoC frameworks themselves.  I totally
> > agree Struts shouldn't become some generic IoC framework, hence my
> > suggestion of using Spring.
>
> Something Craig mentioned way back when was:
>
> * Ensure that all framework objects in 2.0 have consistent factory-based
> mechanisms to instantiate instances.
> 
>
> is this an area where we could use Spring in our implemention?
>
> -Ted.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread gvanmatre

We have a solution for dynamic page content that is component based.  I
wouldnt say that it stands up to JSF but its similar in concept.  The
content of the page is defined using xml metadata.

However, I suppose that you could argue, why not use JSF?  I would be
interested in hearing what advantage you would have using struts with JSF
when JSF handles both the view layer and controller?

Consider the following DTD and XML snippet:











This is an example of building a change password page.  The
"changePasswdForm" is the root "component".





   







  
  

  
  

  

  

  

  
 
  

  
 
  








   
  
  
  
   

   

  
  
  
   



> At 3:47 PM + 12/19/03, PILGRIM, Peter, FM wrote:
>>Having spoken with Don Brown, I can see the benefits now
>>of the BeanWrapper and the [Xml]BeanFactory in Spring. Creating
>>a graph of objects from an XML file is pretty handy for certain
>>situations. I can see the light of the joke. Objects just
>>"Spring" into life from literal paper.
>>
>>I guess the decision here will be political. "Can we just take
>>or borrow the org.springframework.beans.* of your framework?"
>>Hmmm.
>
> The thing that looks attractive to me in Spring is the ability to  make
> a graph of objects more complicated than a tree.  It would be  possible
> to do this in Digester, without necessarily even writing  custom rule
> classes.
>
> As for PicoContainer, if someone could just show me how you write an
> external configuration file that wires together objects through their
> constructors, I might buy it, but it just doesn't seem to match up.  As
> soon as you had one new collaborator that you hadn't planned for,  you'd
> have to rewrite some java code somewhere, wouldn't you?
>
> That's another facet of Spring that appeals to me -- it's orientation
> towards JavaBean conventions -- but we can achieve that with
> homegrown processes using (or at least inspired by) Digester if we're
> reluctant to pile on Spring.
>
> If Spring uses an Apache license, then politics or not we can use the
> code just about anyway we like, but I don't know that we need to read
> the Spring code to achieve the few things that seem most useful to  me.
> I still haven't found the time to really dig into the various
> microkernel/IoC type frameworks yet, so I hope I'm not just blowing
> smoke...
>
> Joe
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
>   "We want beef in dessert if we can get it there."
>-- Betty Hogan, Director of New Product Development, National
> Cattlemen's Beef Association
>
>
> - To
> unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread Joe Germuska

At 3:47 PM + 12/19/03, PILGRIM, Peter, FM wrote:
Having spoken with Don Brown, I can see the benefits now
of the BeanWrapper and the [Xml]BeanFactory in Spring. Creating
a graph of objects from an XML file is pretty handy for certain
situations. I can see the light of the joke. Objects just
"Spring" into life from literal paper.
I guess the decision here will be political. "Can we just take
or borrow the org.springframework.beans.* of your framework?"
Hmmm.
The thing that looks attractive to me in Spring is the ability to 
make a graph of objects more complicated than a tree.  It would be 
possible to do this in Digester, without necessarily even writing 
custom rule classes.

As for PicoContainer, if someone could just show me how you write an 
external configuration file that wires together objects through their 
constructors, I might buy it, but it just doesn't seem to match up. 
As soon as you had one new collaborator that you hadn't planned for, 
you'd have to rewrite some java code somewhere, wouldn't you?

That's another facet of Spring that appeals to me -- it's orientation 
towards JavaBean conventions -- but we can achieve that with 
homegrown processes using (or at least inspired by) Digester if we're 
reluctant to pile on Spring.

If Spring uses an Apache license, then politics or not we can use the 
code just about anyway we like, but I don't know that we need to read 
the Spring code to achieve the few things that seem most useful to 
me.  I still haven't found the time to really dig into the various 
microkernel/IoC type frameworks yet, so I hope I'm not just blowing 
smoke...

Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
 "We want beef in dessert if we can get it there."
  -- Betty Hogan, Director of New Product Development, National 
Cattlemen's Beef Association

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

David Graham wrote:
If we want IoC inside of Struts we should look at something lighter weight
like HiveMind.  I'd also like some focused concrete examples of how IoC
would benefit Struts internals before we decide to go that route.  
I think this is an important point. All we can do here is "decide to 
decide". The only decisions that matter come when we check-in code. And, 
 until code is on the table, we really can't decide anything.

Even if we did "decide" to try this or that, I do hope one of us would 
veto the implementation if it didn't make the grade (and then provide a 
viable alternative). Regardless of what discussions we have, our 
responsibility to the community to make Struts "the best it can be" 
trumps all.

When we get to the part where we can use something like Spring or 
Hivemind or Cornerstone, et al, someone can post some code, and then we 
can decide on the merits. And if no one coughs up the code, then we just 
stay the course.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread PILGRIM, Peter, FM

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich

==///==

> 
> Craig R. McClanahan wrote:
> >
> 
> > 
> > There's a couple of variations on the theme that are 
> possible, but I can think
> > of at least three layers of something that might be called 
> a "form bean" in the
> > conceptual sense:
> > 
> > (1) A set of typesafe field names and corersponding values
> > where the application doesn't have to worry about maintaining
> > values across requests.
> > - Variation:  dynamically add and remove fields as needed
> > - Variation:  allow non-typesafe fields
> > - Variation:  allow fields that can have multiple 
> values (arrays)
> > - Variation:  represent data hierarchically instead of just
> >   a name-value map (bean properties, nested expressions,
> >   XML DOM, what have you)
> > 
> > (2) The above plus a mechanism to define validation rules 
> (correctness
> > checks) on the field values that are independent of physical
> > presentation
> > - Variation:  hard coded logic for validations (i.e. 
> the original
> >   validate() method in Struts ActionForms.
> > - Variation:  pointer to a configured set of validation rules
> >   that is abstracted from presentation considerations.  
> > 
> > (3) All of the above plus event handlers for UI events that change
> > the state of the field values -- perhaps in the same bean,
> > perhaps somewhere else.
> > 
> > A type (1) or type (2) form bean is really better thought 
> of as an abstract way
> > to pass the input data for some sort of business 
> transaction between tiers, or
> > within tiers.  A type (3) form bean would definitely live 
> in the presentation
> > tier, and not be used between them.  For all three of the 
> cases, though, we
> > probably want to invent a different term than "form bean" 
> because that seems so
> > conceptually tied to presentation only.  Transaction Bean?  
> Input Bean?  Data
> > Transfer Object :-)?
> 
> 
> Can't it be just one good old View layer "thing" that maps the 
> properties and it's still called formBean? KISS
> 
> Don did not link XMLForms good, here are better links for a 
> real fun read:
> 
> http://webservices.xml.com/lpt/a/ws/2003/01/29/cocoon-xforms.html
> 
> http://www.cocoonhive.org/xmlform/index.html
> 
> I like that Pico is lightest IoC and do not see a need for a Bean 
> Factory, etc.. So there should be some talk of Spring vs Pico.
> 
> 
> So far, if it's built on top of
> -IoC
> -with "XMLFormBean" (as option, since XML can be slow right 
> now, so it 
> needs to support backward compatible FormBean)
> -an execute(context) Action iterface,
> -chain request procesor filter interfaces
> -HTML tag to support XML Submit (including multi row)
> -JDK 1.4
> -Clear testing interface to major user components.
> 
> That could be the broad stroke major center pieces. It is 
> same design as 
> Struts 0.6 with each component refactored, same diagram.
> 
> 
> There are several smaller pieces, but if Struts can stay 
> light without 
> too many moving parts, better, people can put arms arround it.
> XML config wishes:
> - all xml files be able to extend like tiles, like in Validator
> - move form beam declaration section to validator, no need to 
> do it 2 times.
> - move all tiles xml to struts config, and get rid of tiles.xml
> - have a forward to a tile declaration allow you to name the "base" 
> definition and tile to replace, even maybe have tile part of 
> "* forward" 
> or what ever Don's thing is called.
> 

This would involve XML namespacing for Struts DTD, but Ted has 
already addressed, if you want to make gigantic configuration
file. I think the simplicity is in the modularity of the XML
files rather than having a monolithic mess/.

> I still kind of think maybe DAO interface should be there, we 
> learned a 
> lot about DAO since.
> 

Data Model should be agnostic regarding Struts.

> (I still think one or 2 people should do it in 48 hours from start 
> else... it's design by comittee)
> 
> .V
> 

Keep in mind that Spring has its own Model View Controller 
package, and Rod Johnson berates Struts 1.0 a little in his book 
"Expert One on One" ... concerning ActionForm themselves.

Having spoken with Don Brown, I can see the benefits now
of the BeanWrapper and the [Xml]BeanFactory in Spring. Creating
a graph of objects from an XML file is pretty handy for certain
situations. I can see the light of the joke. Objects just 
"Spring" into life from literal paper.

I guess the decision here will be political. "Can we just take
or borrow the org.springframework.beans.* of your framework?"
Hmmm. 

--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923


***
The Royal Bank of Scotland plc. Registered in Scotland No 90312.   Registered 
Office: 36 St Andrew Square, Edinburgh EH2 2YB.

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread David Graham


--- Don Brown <[EMAIL PROTECTED]> wrote:
> On Thu, 18 Dec 2003, PILGRIM, Peter, FM wrote:
> 
> > What kind of Spring Framework classes would you want to use in
> > Struts 2.0?
> >
> > The BeanWrapper and the BeanFactory are interesting ideas.
> > An example of configuring commons DBCP is given
> > http://www.springframework.org/docs/lightweight_container.html
> >
> > I am not convince however of the requirement for BeanFactory.
> > I can understand if you need to have massive XML configuration
> > and need to dynamic generate Beans (objects) at run-time.
> > It is great but other than that I can really view to the
> > advantage inverse of control there that Struts or Commons BeanUtils
> > combine Digester could not do itself.
> >
> > Struts is great because it concentrates on doing one thing well MVC.
> > I wouldn't want it to branch out go into a generic framework space
> > e.g Avalon, Expresso, Keel, Spring, Pico etc.
> >
> > The major design difficulties are abstract away the request and
> response
> > objects from the controller actions, and also configuration of any
> > other front-end objects you need along the way. To a certain extent
> > Commons Chain and its context leads the way regarding the former.
> 
> I see Spring as helping Struts be better structure its internal
> components, specifically using a BeanFactory implementation.  It would
> not
> replace struts-config in any way or even be exposed directly the a
> Struts
> application.  The struts-chain request processor implementation makes it
> easy for Struts apps to plug in IoC frameworks themselves.  I totally
> agree Struts shouldn't become some generic IoC framework, hence my
> suggestion of using Spring.
> 
> The reason I think IoC is important for Struts 2.0 is for easier unit
> testing, more componentized development, easier to plug in alternate
> implementions of components like file upload, better dependency
> management, less object references, and easier for the advanced user to
> extend Struts in interesting ways.  Notice these advantages are targeted
> for Struts developers and advanced Struts users.

The IoC topic deserves its own thread.  Spring is bloated.  It contains a
DAO layer, JDBC helper library, Web MVC framework, IoC support, etc.  I
don't think we should be lugging around Spring inside of Struts.  There
are also non-technical aspects of Spring that have lowered my opinion of
it.

If we want IoC inside of Struts we should look at something lighter weight
like HiveMind.  I'd also like some focused concrete examples of how IoC
would benefit Struts internals before we decide to go that route.  

David

> 
> Don
> 
> 
> >
> > --
> > Peter Pilgrim,
> > Struts/J2EE Consultant, RBoS FM, Risk IT
> > Tel: +44 (0)207-375-4923


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Do we still want to integrate stxx into Struts 1.x?

Don Brown wrote:
Using JXPath is exactly what XMLForms (http://www.xmlforms.org) does to
allow the form model to be anything from a DOM to a JavaBean or even a
DynaBean.  XMLForms came out of Cocoon, but I believe they still use
something simliar.  In stxx (http://stxx.sf.net), a Struts extension, I
have been  experimenting using XML as the data model for a form.  It is
particuarly useful as it allows forms to be simultaneously exposed via
Struts and SOAP.
Don




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Don Brown wrote:
I see Spring as helping Struts be better structure its internal
components, specifically using a BeanFactory implementation.  It would not
replace struts-config in any way or even be exposed directly the a Struts
application.  The struts-chain request processor implementation makes it
easy for Struts apps to plug in IoC frameworks themselves.  I totally
agree Struts shouldn't become some generic IoC framework, hence my
suggestion of using Spring.
Something Craig mentioned way back when was:

* Ensure that all framework objects in 2.0 have consistent factory-based 
mechanisms to instantiate instances. 


is this an area where we could use Spring in our implemention?

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread stutz

I am using a kind of bi-directional convertion (Form<->DTO) in my project.
I have the form with all fields type String that are converted to a DTO of
typed fields.
I tryed to use LocaleBeanUtils and I found some bugs as I fixed them and
will send the patches to the Commons Project. It is working all right here
considering the user Locale (parsing internationalized values of dates,
time, numbers... and printing (converting to String) them in a
internationalized format too) and so on.
I am on vacation and will be out for about 5 weeks (marriage!!!), so if you
want the patched codes to send to jakarta-commons, tell me and I will
attach it to bugzilla #24941.

http://issues.apache.org/bugzilla/show_bug.cgi?id=24941

Stutz

 Para:   Struts Developers List <[EMAIL 
PROTECTED]>
   Hubert Rabago cc:   

   <[EMAIL PROTECTED]Assunto: Re: Struts 2.0 Ideas (was Re: 
Struts 2.0 Discussion Forum)   
   .com>   

   12/18/2003 09:02

   PM PST  

   Responder a 

   "Struts Developers  

   List"   

That's exactly what I meant to say, of course I just didn't articulate it
as well
as you did. =)  Form bean details are spread all around, violating the DRY
principle.  The DTO's can be used to tell Struts how to generate dynamic
action
forms that it (and the validator) can work with, without the user having to
list
down all the fields in the struts config file.  Also, the conversion from
ActionForm to app-specific DTO's can mostly be automated.

You're already working on it -- that's great news!  Just give a shout out
if you
need any sort of help (coding, testing, whatever).  I was gonna propose a
possible implementation, but since you've got something going already, I'd
like
to help out with that instead.

I'm thinking this is something that doesn't need to wait for 2.0 to be
useful, or
at least it's something that can be developed to work for 1.x with an eye
towards
2.x/Jericho compatibility.  Or, design it for 2.x and make it 1.x
compatible.
Whatever.  I just wanna stop repeating field names between DTO and form
beans.  I
suppose laziness really is the father of innovation.

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> The gotcha is that a DTO usually has typed fields, and can't redisplay
> invalid data. An ActionForm is specifically designed to capture String
> input, validate it, then redisplay it if necessary, so it can then be
> converted to whatever type is desired. Most DTO's aren't up for this
> type of gauntlet.
>
> What I would like to do is merge (2) and (3), and add additional
> properties so that an input form can be fully described. Right now, we
> have form details spread across the sturts-config, validations.xml, and
> the server page. A central element that could render most of the form
> for you (including i18n labels, hints, and so forth), would eliminate a
> lot of the redundancy we face today.
>
> I'd also like to include bi-directional data-converters in the form
> element, to close the loop. So, after validating the input, we could
> extract a populated DTO from a factory-type method. Likewise, we could
> pass a DTO to the form object and have it convert the binary types to
> properly-formatted Strings.
>
> Right now, I'm working on this using FormProc and Maverick (SourceForge
> projects) and hope to move it to Struts soon.
>
> -Ted.
>
> Hubert Rabago wrote:
> > I think we're tackling different issues here.
> > What I'm trying to avaoid is having (1) a d

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread Vic Cekvenich



Craig R. McClanahan wrote:


There's a couple of variations on the theme that are possible, but I can think
of at least three layers of something that might be called a "form bean" in the
conceptual sense:
(1) A set of typesafe field names and corersponding values
where the application doesn't have to worry about maintaining
values across requests.
- Variation:  dynamically add and remove fields as needed
- Variation:  allow non-typesafe fields
- Variation:  allow fields that can have multiple values (arrays)
- Variation:  represent data hierarchically instead of just
  a name-value map (bean properties, nested expressions,
  XML DOM, what have you)
(2) The above plus a mechanism to define validation rules (correctness
checks) on the field values that are independent of physical
presentation
- Variation:  hard coded logic for validations (i.e. the original
  validate() method in Struts ActionForms.
- Variation:  pointer to a configured set of validation rules
  that is abstracted from presentation considerations.  

(3) All of the above plus event handlers for UI events that change
the state of the field values -- perhaps in the same bean,
perhaps somewhere else.
A type (1) or type (2) form bean is really better thought of as an abstract way
to pass the input data for some sort of business transaction between tiers, or
within tiers.  A type (3) form bean would definitely live in the presentation
tier, and not be used between them.  For all three of the cases, though, we
probably want to invent a different term than "form bean" because that seems so
conceptually tied to presentation only.  Transaction Bean?  Input Bean?  Data
Transfer Object :-)?


Can't it be just one good old View layer "thing" that maps the 
properties and it's still called formBean? KISS

Don did not link XMLForms good, here are better links for a real fun read:

http://webservices.xml.com/lpt/a/ws/2003/01/29/cocoon-xforms.html

http://www.cocoonhive.org/xmlform/index.html

I like that Pico is lightest IoC and do not see a need for a Bean 
Factory, etc.. So there should be some talk of Spring vs Pico.

So far, if it's built on top of
-IoC
-with "XMLFormBean" (as option, since XML can be slow right now, so it 
needs to support backward compatible FormBean)
-an execute(context) Action iterface,
-chain request procesor filter interfaces
-HTML tag to support XML Submit (including multi row)
-JDK 1.4
-Clear testing interface to major user components.

That could be the broad stroke major center pieces. It is same design as 
Struts 0.6 with each component refactored, same diagram.

There are several smaller pieces, but if Struts can stay light without 
too many moving parts, better, people can put arms arround it.
XML config wishes:
- all xml files be able to extend like tiles, like in Validator
- move form beam declaration section to validator, no need to do it 2 times.
- move all tiles xml to struts config, and get rid of tiles.xml
- have a forward to a tile declaration allow you to name the "base" 
definition and tile to replace, even maybe have tile part of "* forward" 
or what ever Don's thing is called.

I still kind of think maybe DAO interface should be there, we learned a 
lot about DAO since.

(I still think one or 2 people should do it in 48 hours from start 
else... it's design by comittee)

.V









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

On Thu, 18 Dec 2003, PILGRIM, Peter, FM wrote:

> What kind of Spring Framework classes would you want to use in
> Struts 2.0?
>
> The BeanWrapper and the BeanFactory are interesting ideas.
> An example of configuring commons DBCP is given
> http://www.springframework.org/docs/lightweight_container.html
>
> I am not convince however of the requirement for BeanFactory.
> I can understand if you need to have massive XML configuration
> and need to dynamic generate Beans (objects) at run-time.
> It is great but other than that I can really view to the
> advantage inverse of control there that Struts or Commons BeanUtils
> combine Digester could not do itself.
>
> Struts is great because it concentrates on doing one thing well MVC.
> I wouldn't want it to branch out go into a generic framework space
> e.g Avalon, Expresso, Keel, Spring, Pico etc.
>
> The major design difficulties are abstract away the request and response
> objects from the controller actions, and also configuration of any
> other front-end objects you need along the way. To a certain extent
> Commons Chain and its context leads the way regarding the former.

I see Spring as helping Struts be better structure its internal
components, specifically using a BeanFactory implementation.  It would not
replace struts-config in any way or even be exposed directly the a Struts
application.  The struts-chain request processor implementation makes it
easy for Struts apps to plug in IoC frameworks themselves.  I totally
agree Struts shouldn't become some generic IoC framework, hence my
suggestion of using Spring.

The reason I think IoC is important for Struts 2.0 is for easier unit
testing, more componentized development, easier to plug in alternate
implementions of components like file upload, better dependency
management, less object references, and easier for the advanced user to
extend Struts in interesting ways.  Notice these advantages are targeted
for Struts developers and advanced Struts users.

Don


>
> --
> Peter Pilgrim,
> Struts/J2EE Consultant, RBoS FM, Risk IT
> Tel: +44 (0)207-375-4923
>
>
> ***
> The Royal Bank of Scotland plc. Registered in Scotland No 90312.   Registered 
> Office: 36 St Andrew Square, Edinburgh EH2 2YB.
> Authorised and regulated by the Financial Services Authority
>
> This e-mail message is confidential and for use by the
> addressee only. If the message is received by anyone other
> than the addressee, please return the message to the sender
> by replying to it and then delete the message from your
> computer. Internet e-mails are not necessarily secure. The
> Royal Bank of Scotland plc does not accept responsibility for
> changes made to this message after it was sent.
>
> Whilst all reasonable care has been taken to avoid the
> transmission of viruses, it is the responsibility of the recipient to
> ensure that the onward transmission, opening or use of this
> message and any attachments will not adversely affect its
> systems or data.  No responsibility is accepted by The Royal
> Bank of Scotland plc in this regard and the recipient should carry
> out such virus and other checks as it considers appropriate.
>  
>   Visit our websites at:
> http://www.rbs.co.uk/CBFM
> http://www.rbsmarkets.com
>  
>   
> 
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Using JXPath is exactly what XMLForms (http://www.xmlforms.org) does to
allow the form model to be anything from a DOM to a JavaBean or even a
DynaBean.  XMLForms came out of Cocoon, but I believe they still use
something simliar.  In stxx (http://stxx.sf.net), a Struts extension, I
have been  experimenting using XML as the data model for a form.  It is
particuarly useful as it allows forms to be simultaneously exposed via
Struts and SOAP.

Don

On Thu, 18 Dec 2003, Craig R. McClanahan wrote:

> Quoting Mete Kural <[EMAIL PROTECTED]>:
>
> > >I am thinking of fliping sides on FormBean as interface, I am now
> > >leaning against formbeans being an interface. FormBean is a concept
> > >(properties that map to form elements), plus this idea of XML as a
> > >FormBean. It could be a List or String or anything.
> >
> > XML as a FormBean! That got my attention...
> >
> > Say we want to populate customer information where a user can edit it like in
> > an Excel spreadsheet. If the Action accesses a web service and receives a
> > SOAP response and some XML objects in the SOAP response, sometimes it is too
> > much processing to convert XML to Java objects if it is a lot of XML (for
> > example: If the web service returns a list of 50 customers with detailed
> > info). In such cases it may make more sense to do an XSLT transformation over
> > the XML objects and render the form. Any suggestions on how this could be
> > done in Struts 2.0?
> >
>
> The key to this, IMHO, is the expression language used to bind a reference to a
> field (say, in a JSP page) to some underlying data object representing the
> field's value.
>
> One very simple approach would be to teach BeanUtils and PropertyUtils how to
> treat the "." operator differently when the base object is an Element (from the
> DOM API) ... it would find a child element with an element name equal to the
> "property name".  This would deal directly with any XML document totally based
> on elements (as opposed to attributes), in a very simple (and mostly backwards
> compatible) way, so it could therefore even be implemented in Struts 1.2.x.
>
> A more comprehensive (but tied to XML) approach would be to support the use of
> XPath for referencing elements and attributes in a DOM ... but ideally have a
> way to access "trees of JavaBeans" using the same search expressions.  Tools
> like commons-jxpath make that pretty easy to do as well.
>
> If you can have pluggability in your binding expressions, you can adapt to
> pretty much any internal data representation.  (That's one of the key reasons,
> for example, that JavaServer Faces supports pluggable VariableResolver and
> PropertyResolver implementations).
>
> > Thanks,
> > Mete
> >
>
> Craig
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

I totally agree - let me clarify.  I think Struts 2.0 could use an IoC
framework like Spring to help improve its internal structure.  Any
configuration files should be stored in the Struts jar, but be able to be
overridden by specifying an alternate IoC configuration path.  This lets
advanced users easily modify the structure of Struts itself, but not add
complexity for the casual user.  Of course, Spring and probably other
frameworks allow you to easily customize the configuration process.

Don

On Thu, 18 Dec 2003, Martin Cooper wrote:

> On Wed, 17 Dec 2003, Don Brown wrote:
>
> > Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> > release work. :)  I'll throw out some ideas here, then develop them later
> > in the wiki:
> >
> > - Make Inversion of Control central.  By using an IoC framework to wire
> > Struts together, it makes it really easy to extend or improve Struts not
> > only for future development but for users as well.  I'd recommend Spring's
> > IoC impl as it is small (>100k), really easy to use, and easily
> > extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
> > frameworks that let you plug in Pico/Spring/Avalon, etc.
>
> I'm a little hesitant to start depending on other frameworks. It's not
> that I think they don't have anything to offer us, it's just what it does
> to the newcomer to Struts. If someone has to learn Struts *and* Spring
> (for example) to get going, then we've set the bar much higher.
>
> If we do end up deciding to depend on something like this, I believe we'll
> need to put in the work to make it "look" like Struts. Taking Spring as an
> example again, the substantial difference in the "character" of the XML
> config files would easily confuse a newcomer trying to get his/her head
> around the syntax. If we could make those files "look" like Struts config
> files (or vice versa, for that matter), that would help, though.
>
> --
> Martin Cooper
>
>
> >
> > - Use XML Schema over DTD's.  Give struts config its own default namespace
> > to make it easier for users to mix in elements of other namespaces.  An
> > example would be adding custom documentation attributes and elements.  Of
> > course the usual arguments for XML Schema over DTD's apply as well.
> >
> > - Replace paths with URL's, allowing for a default protocol.  An action
> > path would look like "action://foo" or a tiles forward would be
> > "tiles://tilesdef"  This would make it easy to plug in handlers to support
> > different presentation engines.  If no protocol is specified, the path is
> > handled as usual.
> >
> > - As Ted said, contine with the wildcard theme.  Struts should do
> > everything possible to cut down configuration.
> >
> > - Also, again totally agreeing with Ted, make everything interface based,
> > have default implementations, and free apps of HTTP.  Ideally, I'd like to
> > see extra effort going into making it easy if not effortless to take a
> > Struts 2.0 app and use the code in a portlet or web service environment.
> > At least in my area, clients are wanting human and machine interfaces,
> > with the human interface generally being behind a portal.
> >
> > Anyways, those are my "brainstorming" thoughts.  If any look interesting,
> > I'll write something up in the wiki.
> >
> > Don
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-19 Thread Hubert Rabago

I'm not looking to get rid of the ActionForm objects, just automate its creation
based on my DTO for cases where it makes sense.
Today, a lot of my forms do something like this:

1. Caller brings up the page with Form A (let's say an Edit Record form)
2. Action responds by requesting data from business tier and gets a DTO
3. Action converts DTO into ActionForm (AF) to represent all fields as strings
4. JSP shows form with values from AF
5. Form gets submitted after user edits it
6. Action receives AF and converts the data to populate a DTO
7. DTO is sent to business tier for processing

What I'm thinking is automating steps 3 and 6, and automate the definition of the
AF.  There will still be an AF for the reasons you've given, it's just that when
there's a close match between the DTO and the AF, the programmer can just let the
framework take care of defining the AF (or the DynaAF, in this case) and
populating it from the DTO.  That way, if my DTO already has fields for name
(String), age (int), and birthDate (Date), I won't have to explicitly outline a
DynaActionForm with name, age, and birthDate fields and manage the conversion. 
The framework would be able to do it for me.  Yes, some config file will still
say "Convert dates using this pattern; For this specific form or field, use this
pattern" but most other fields can be automated with little config requirements.

There'll still be an ActionForm (or the Type 2 conceptual bean you earlier
described) and it's still what gets passed to the JSP and to the validator.  I
just want the framework to know what fields should be on the ActionForm based on
a DTO I'll supply, instead of making me type it into the struts-config or
creating a new class that's basically String-based counterpart.

Of course, this won't match each and every use case; I don't have a one-to-one
relationship between my AFs and DTOs.  I'm just looking to use something like
this when I find myself creating a String-ified version of an existing DTO.

thanks,
Hubert

--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> 
> That turns out to be more intricate than it first appears, and is the reason
> that ActionForm existed in the first place (and, why it's part of the *view*
> tier, not the model, and why it was originally created as a class and not an
> interface, to discourage people from using it as a DTO).
> 
> A very important feature of any presentation tier is to be able to reproduce
> whatever the user entered, even if they made a mistake (i.e. typed "1a3"
> instead of "123" into a field that is backed by an int).  Given the
> practicalities of HTTP, that gives you two basic choices:
> 
> * A framework that represents input fields on the server side as
>   Strings, and then requires post-validation conversion (basically
>   the Struts 1.x model).
> 
> * A framework where the individual user interface components manage
>   their own conversions, and are bound to back-end DTOs or model data
>   objects expressed as native data types (JavaServer Faces, Tapestry,
>   and several other frameworks work this way).
> 
> Interstingly, using JavaServer Faces components in front of Struts ActionForms
> will let you work the second way if you want to, and use action forms that have
> native data types with no problems.
> 
> You'll also find that there is not always (or even often, in my experience) a
> 1:1 relationship between "the sets of fields on a form" and "the set of model
> data objects that provide information to, or accept updates from, that form". 
> My feeling is that you're always going to want separate abstractions; the
> secret for a framework is to minimize the amount of work required to deal wth
> that reality.
> 
> Craig
> 

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Hubert Rabago <[EMAIL PROTECTED]>:

> That's exactly what I meant to say, of course I just didn't articulate it as
> well
> as you did. =)  Form bean details are spread all around, violating the DRY
> principle.  The DTO's can be used to tell Struts how to generate dynamic
> action
> forms that it (and the validator) can work with, without the user having to
> list
> down all the fields in the struts config file.  Also, the conversion from
> ActionForm to app-specific DTO's can mostly be automated.
> 

That turns out to be more intricate than it first appears, and is the reason
that ActionForm existed in the first place (and, why it's part of the *view*
tier, not the model, and why it was originally created as a class and not an
interface, to discourage people from using it as a DTO).

A very important feature of any presentation tier is to be able to reproduce
whatever the user entered, even if they made a mistake (i.e. typed "1a3"
instead of "123" into a field that is backed by an int).  Given the
practicalities of HTTP, that gives you two basic choices:

* A framework that represents input fields on the server side as
  Strings, and then requires post-validation conversion (basically
  the Struts 1.x model).

* A framework where the individual user interface components manage
  their own conversions, and are bound to back-end DTOs or model data
  objects expressed as native data types (JavaServer Faces, Tapestry,
  and several other frameworks work this way).

Interstingly, using JavaServer Faces components in front of Struts ActionForms
will let you work the second way if you want to, and use action forms that have
native data types with no problems.

You'll also find that there is not always (or even often, in my experience) a
1:1 relationship between "the sets of fields on a form" and "the set of model
data objects that provide information to, or accept updates from, that form". 
My feeling is that you're always going to want separate abstractions; the
secret for a framework is to minimize the amount of work required to deal wth
that reality.

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Hubert Rabago

That's exactly what I meant to say, of course I just didn't articulate it as well
as you did. =)  Form bean details are spread all around, violating the DRY
principle.  The DTO's can be used to tell Struts how to generate dynamic action
forms that it (and the validator) can work with, without the user having to list
down all the fields in the struts config file.  Also, the conversion from
ActionForm to app-specific DTO's can mostly be automated.

You're already working on it -- that's great news!  Just give a shout out if you
need any sort of help (coding, testing, whatever).  I was gonna propose a
possible implementation, but since you've got something going already, I'd like
to help out with that instead.

I'm thinking this is something that doesn't need to wait for 2.0 to be useful, or
at least it's something that can be developed to work for 1.x with an eye towards
2.x/Jericho compatibility.  Or, design it for 2.x and make it 1.x compatible.
Whatever.  I just wanna stop repeating field names between DTO and form beans.  I
suppose laziness really is the father of innovation.

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> The gotcha is that a DTO usually has typed fields, and can't redisplay 
> invalid data. An ActionForm is specifically designed to capture String 
> input, validate it, then redisplay it if necessary, so it can then be 
> converted to whatever type is desired. Most DTO's aren't up for this 
> type of gauntlet.
> 
> What I would like to do is merge (2) and (3), and add additional 
> properties so that an input form can be fully described. Right now, we 
> have form details spread across the sturts-config, validations.xml, and 
> the server page. A central element that could render most of the form 
> for you (including i18n labels, hints, and so forth), would eliminate a 
> lot of the redundancy we face today.
> 
> I'd also like to include bi-directional data-converters in the form 
> element, to close the loop. So, after validating the input, we could 
> extract a populated DTO from a factory-type method. Likewise, we could 
> pass a DTO to the form object and have it convert the binary types to 
> properly-formatted Strings.
> 
> Right now, I'm working on this using FormProc and Maverick (SourceForge 
> projects) and hope to move it to Struts soon.
> 
> -Ted.
> 
> Hubert Rabago wrote:
> > I think we're tackling different issues here.
> > What I'm trying to avaoid is having (1) a data transfer object used by the
> > different tiers, and (2) a form bean object or dyna form bean definition
> which is
> > a close reflection of the fields that the DTO already defines, and (3) a
> > validation rule xml which lists down all/most of the fields along with rules
> on
> > how to validate each.
> > Of course, I'll also need to write code to convert my DTO to a form bean and
> vice
> > versa.
> > I'm thinking we can lose the explicit form bean definition and the code which
> > converts between the DTO and form bean.
> > 
> > 
> > --- Mete Kural <[EMAIL PROTECTED]> wrote:
> > 
> >>>For a given form/action, the framework will be supplied with the FQCN of the
> >>>DTO/VO.  From there, it can determine what the fields of the form will be. 
> >>
> >>The
> >>
> >>>form bean validation/descriptor XML will provide the validation information
> >>
> >>and
> >>
> >>>any conversion rules as needed to format/parse between the value object and
> >>
> >>the
> >>
> >>>string representation for the form bean.
> >>
> >>That sounds very interesting. I think there is interest in having support for
> >>dynamic forms where the fields of the form are determined dynamically rather
> >>than hardcoded in the JSP. What are the ideas on how to handle dynamic field
> >>names (and number of fields) in Struts 2.0? 
> >>
> >>Let's say that we are designing a dynamic customer information editing form.
> >>Every user has different preferences on what fields they want to edit or
> >>allowed to edit. Action class accesses a web service and receives a SOAP
> >>response with exactly those fields that are fit for this user. How could
> Struts
> >>assemble the form dynamically and pre-populate the customer information and
> >>then validate it when the user submits?
> >>
> >>Regards,
> >>Mete
> >>


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

The gotcha is that a DTO usually has typed fields, and can't redisplay 
invalid data. An ActionForm is specifically designed to capture String 
input, validate it, then redisplay it if necessary, so it can then be 
converted to whatever type is desired. Most DTO's aren't up for this 
type of gauntlet.

What I would like to do is merge (2) and (3), and add additional 
properties so that an input form can be fully described. Right now, we 
have form details spread across the sturts-config, validations.xml, and 
the server page. A central element that could render most of the form 
for you (including i18n labels, hints, and so forth), would eliminate a 
lot of the redundancy we face today.

I'd also like to include bi-directional data-converters in the form 
element, to close the loop. So, after validating the input, we could 
extract a populated DTO from a factory-type method. Likewise, we could 
pass a DTO to the form object and have it convert the binary types to 
properly-formatted Strings.

Right now, I'm working on this using FormProc and Maverick (SourceForge 
projects) and hope to move it to Struts soon.

-Ted.

Hubert Rabago wrote:
I think we're tackling different issues here.
What I'm trying to avaoid is having (1) a data transfer object used by the
different tiers, and (2) a form bean object or dyna form bean definition which is
a close reflection of the fields that the DTO already defines, and (3) a
validation rule xml which lists down all/most of the fields along with rules on
how to validate each.
Of course, I'll also need to write code to convert my DTO to a form bean and vice
versa.
I'm thinking we can lose the explicit form bean definition and the code which
converts between the DTO and form bean.
--- Mete Kural <[EMAIL PROTECTED]> wrote:

For a given form/action, the framework will be supplied with the FQCN of the
DTO/VO.  From there, it can determine what the fields of the form will be. 
The

form bean validation/descriptor XML will provide the validation information
and

any conversion rules as needed to format/parse between the value object and
the

string representation for the form bean.
That sounds very interesting. I think there is interest in having support for
dynamic forms where the fields of the form are determined dynamically rather
than hardcoded in the JSP. What are the ideas on how to handle dynamic field
names (and number of fields) in Struts 2.0? 

Let's say that we are designing a dynamic customer information editing form.
Every user has different preferences on what fields they want to edit or
allowed to edit. Action class accesses a web service and receives a SOAP
response with exactly those fields that are fit for this user. How could Struts
assemble the form dynamically and pre-populate the customer information and
then validate it when the user submits?
Regards,
Mete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Craig R. McClanahan wrote:
Quoting Ted Husted <[EMAIL PROTECTED]>:
InputHandler?
That would certainly be an appropriate name for my type (3) form bean (that
included event handling), and perhaps even for a type (2) form bean that
includes some sort of hooks into validation.  It doesn't fit the type (1) style
that contains only data, though.
Yes, that one sounds more like an InputContext (that InputHandlers might 
extend).

-T.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Ted Husted <[EMAIL PROTECTED]>:

> Craig R. McClanahan wrote:
> > For all three of the cases, though, we
> > probably want to invent a different term than "form bean" because that
> seems so
> > conceptually tied to presentation only.  Transaction Bean?  Input Bean? 
> Data
> > Transfer Object :-)?
> 
> InputHandler?
> 

That would certainly be an appropriate name for my type (3) form bean (that
included event handling), and perhaps even for a type (2) form bean that
includes some sort of hooks into validation.  It doesn't fit the type (1) style
that contains only data, though.

> -T.
> 
> 

Craig

> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Mete Kural <[EMAIL PROTECTED]>:

> >I am thinking of fliping sides on FormBean as interface, I am now 
> >leaning against formbeans being an interface. FormBean is a concept 
> >(properties that map to form elements), plus this idea of XML as a 
> >FormBean. It could be a List or String or anything.
> 
> XML as a FormBean! That got my attention...
> 
> Say we want to populate customer information where a user can edit it like in
> an Excel spreadsheet. If the Action accesses a web service and receives a
> SOAP response and some XML objects in the SOAP response, sometimes it is too
> much processing to convert XML to Java objects if it is a lot of XML (for
> example: If the web service returns a list of 50 customers with detailed
> info). In such cases it may make more sense to do an XSLT transformation over
> the XML objects and render the form. Any suggestions on how this could be
> done in Struts 2.0?
> 

The key to this, IMHO, is the expression language used to bind a reference to a
field (say, in a JSP page) to some underlying data object representing the
field's value.

One very simple approach would be to teach BeanUtils and PropertyUtils how to
treat the "." operator differently when the base object is an Element (from the
DOM API) ... it would find a child element with an element name equal to the
"property name".  This would deal directly with any XML document totally based
on elements (as opposed to attributes), in a very simple (and mostly backwards
compatible) way, so it could therefore even be implemented in Struts 1.2.x.

A more comprehensive (but tied to XML) approach would be to support the use of
XPath for referencing elements and attributes in a DOM ... but ideally have a
way to access "trees of JavaBeans" using the same search expressions.  Tools
like commons-jxpath make that pretty easy to do as well.

If you can have pluggability in your binding expressions, you can adapt to
pretty much any internal data representation.  (That's one of the key reasons,
for example, that JavaServer Faces supports pluggable VariableResolver and
PropertyResolver implementations).

> Thanks,
> Mete
> 

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Craig R. McClanahan wrote:
For all three of the cases, though, we
probably want to invent a different term than "form bean" because that seems so
conceptually tied to presentation only.  Transaction Bean?  Input Bean?  Data
Transfer Object :-)?
InputHandler?

-T.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Vic Cekvenich <[EMAIL PROTECTED]>:

> 
> 
> Craig R. McClanahan wrote:
> 
> > 
> > One of the things people have said they liked about using a chain to
> decompose
> > RequestProcessor is that you could easily compose your own chains, adding
> your
> > own custom processing stages and so on.  You can do exactly the same thing
> with
> > Filters by making each processXxx method its own filter, and using (say)
> the
> > request attributes to play the role of the Context object in
> commons-chain.
> > 
> > Filters have an additional capability if you're building a
> servlet-specific
> > framework -- they can wrap the actual request and response objects that
> are
> > passed on to the next filter in the chain, so you can implement some
> > interesting things not directly possible with a chain based implementation
> --
> > such as caching or on-the-fly compression of the response.
> > 
> > 
> > 
> > Craig
> 
> I do not get chains, but Hookom posted this link:
>
http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
> 
> which I sort of get (sort of) and it's my favoirte chain impl.
> 

InterceptingFilter (as presented in the Core J2EE Patterns book) is very similar
to the way standard filters work in Servlet 2.3 (and 2.4).  The primary
difference from the way commons-chain works from the presented "Custom Filter
Strategy" is that a Filter cannot say "I have completed the response -- no need
to do anything more", which is exactly what you'd want for things like a "check
that the user has logged in" mechanism.

Doing chains the way that servlet filters do it (each filter explicitly calls
the next in the chain) would eliminate that problem, but has two potential
disadvantages:

* Somebody has to deal with the complexity of falling off the
  end of the filter chain (i.e. a FilterManager or something)

* You end up with a stack frame per Filter (if you've ever wondered
  why Tomcat's stack traces are so long, it's because the Valve
  architecture inside Catalina follows this same design pattern).

> So if we can use filters or other chain, somone clever could write an 
> "chainRequestProcessor" *interface*, that could be impledented for 
> JSP2.0 filter... and then somone else could later write a JSP 1.2 
> version, even non filter versions.
> 
> ?
> 
> So I like chain as interface, and action as interface.
> 

In commons-chain, the Context, Command, and Chain APIs are all interfaces.  You
can use one of the provided implementations and roll your own.

> I am thinking of fliping sides on FormBean as interface, I am now 
> leaning against formbeans being an interface. FormBean is a concept 
> (properties that map to form elements), plus this idea of XML as a 
> FormBean. It could be a List or String or anything. As long as it itself 
> does not do DAO, and it maps to a form, good. (but do have way to unit 
> test it w/o a container)
> For starters so the JSTL x: tag can be used instead of c:out, plus some 
> Stxx things.
> (Then maybe a way to make HTML tag submit XML Doc, multi row and all).
> 
> .V
> 

There's a couple of variations on the theme that are possible, but I can think
of at least three layers of something that might be called a "form bean" in the
conceptual sense:

(1) A set of typesafe field names and corersponding values
where the application doesn't have to worry about maintaining
values across requests.
- Variation:  dynamically add and remove fields as needed
- Variation:  allow non-typesafe fields
- Variation:  allow fields that can have multiple values (arrays)
- Variation:  represent data hierarchically instead of just
  a name-value map (bean properties, nested expressions,
  XML DOM, what have you)

(2) The above plus a mechanism to define validation rules (correctness
checks) on the field values that are independent of physical
presentation
- Variation:  hard coded logic for validations (i.e. the original
  validate() method in Struts ActionForms.
- Variation:  pointer to a configured set of validation rules
  that is abstracted from presentation considerations.  

(3) All of the above plus event handlers for UI events that change
the state of the field values -- perhaps in the same bean,
perhaps somewhere else.

A type (1) or type (2) form bean is really better thought of as an abstract way
to pass the input data for some sort of business transaction between tiers, or
within tiers.  A type (3) form bean would definitely live in the presentation
tier, and not be used between them.  For all three of the cases, though, we
probably want to invent a different term than "form bean" because that seems so
conceptually tied to presentation only.  Transaction Bean?  Input Bean?  Data
Transfer Object :-)?

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Mete Kural

>The "dynamic field" use case comes up all the time, but I have trouble 
>getting my head around it. What would be helpful would be a example 
>application that people could play with. You can take thought 
>experiments only so far :)

Yeah you're right. There needs to be an example application. We have a new project 
where we need to have this dynamic forms ability so hopefully we can come up with some 
example application for others to take a look at.

>My first question would be how would anything (never mind Struts) 
>address this use case?

We don't yet know exactly how (since we haven't built the framework yet). But it'll 
surely involve a lot of Introspection and Reflection APIs.

>-Ted.

-Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Edgar P Dollin

I use dynamic fields all the time.  The fields visible to the user are based
on a usage profile, for example if a user is entering orders and his profile
is for export orders he sees a booking field, if his profile is for domestic
orders he doesn't.

This is a view issue, the booking should be in the model and passed through
struts NMW (I don't believe the small DB optimization is worth the trouble).
The issue to struts and the model is the conditional validation.  There is
one other place where this is a problem and that is with the struts method
of handling checkboxes since all of them on a specific form have to be reset
and if they are conditional in the view it poses a problem although they
pose a problem on a multipage form in any case.

Edgar

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 18, 2003 6:29 PM
> To: Struts Developers List
> Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)


> The "dynamic field" use case comes up all the time, but I have trouble 
> getting my head around it. What would be helpful would be a example 
> application that people could play with. You can take thought 
> experiments only so far :)

> My first question would be how would anything (never mind Struts) 
> address this use case?

> The other half of the problem would be creating a dynamic query to go 
> with the dynamic form, so that only the fields you are editing are
updated.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Ted Husted wrote:
The "dynamic field" use case comes up all the time, but I have trouble 
getting my head around it. What would be helpful would be a example 
application that people could play with.


And making it that dynamic defeats testing and layers.
I am not aware of even Client Server uses cases for dynamic fields.
Simple example: A report for Jasper and SQL.
If you have diferent sql fields, it's a diferent report.
Struts example: Clients give you a mock up of a view somehow, you then 
know the fileds on the view, you know the formbean properties. (and then 
implement a DAO to CRUD the formbean "contract")

So dyamic fields I think should be in the 20% not to be done by core 
Struts.

.V



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

The "dynamic field" use case comes up all the time, but I have trouble
getting my head around it. What would be helpful would be a example
application that people could play with. You can take thought
experiments only so far :)

My first question would be how would anything (never mind Struts)
address this use case?

The other half of the problem would be creating a dynamic query to go
with the dynamic form, so that only the fields you are editing are updated.

-Ted.

Mete Kural wrote:

For a given form/action, the framework will be supplied with the FQCN of the
DTO/VO. From there, it can determine what the fields of the form will be. The
form bean validation/descriptor XML will provide the validation information and
any conversion rules as needed to format/parse between the value object and the
string representation for the form bean.

That sounds very interesting. I think there is interest in having support for dynamic forms where the fields of the form are determined dynamically rather than hardcoded in the JSP. What are the ideas on how to handle dynamic field names (and number of fields) in Struts 2.0?

Let's say that we are designing a dynamic customer information editing form. Every user has different preferences on what fields they want to edit or allowed to edit. Action class accesses a web service and receives a SOAP response with exactly those fields that are fit for this user. How could Struts assemble the form dynamically and pre-populate the customer information and then validate it when the user submits?

Regards,
Mete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

The documentation's a bit sketchy, but the FormProc project in 
SourceForge works this way. The idea is that it validates and populates 
another object directly from the request parameters. At some point, I'd 
like to try to make it an alternative to the Commons/Struts Validator. 
But this would be easier to do once the composable request processor is 
in place.

-Ted.

Hubert Rabago wrote:

--- Mete Kural <[EMAIL PROTECTED]> wrote:

FormBean is a concept 
(properties that map to form elements), plus this idea of XML as a 
FormBean. It could be a List or String or anything.
XML as a FormBean! That got my attention...



What I would like to explore is the possibility of reusing existing DTOs/VOs in
the form beans.  Perhaps they (DTO/VO) won't be used to hold the form values
directly, but the framework can use them to determine the fields of the form. 
The framework can already interpret whether the input string is valid or not,
there's a good chance it'll only take a step or two more to let the framework
convert it to the right data type.
This will really reduce DRY violations between DTO/VO objects, form beans and
validation rule mappings.

For a given form/action, the framework will be supplied with the FQCN of the
DTO/VO.  From there, it can determine what the fields of the form will be.  The
form bean validation/descriptor XML will provide the validation information and
any conversion rules as needed to format/parse between the value object and the
string representation for the form bean.
I've been playing around with this idea for sometime now, and wouldn't mind
working on its code if there's interest in it.
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Hubert Rabago

I think we're tackling different issues here.
What I'm trying to avaoid is having (1) a data transfer object used by the
different tiers, and (2) a form bean object or dyna form bean definition which is
a close reflection of the fields that the DTO already defines, and (3) a
validation rule xml which lists down all/most of the fields along with rules on
how to validate each.
Of course, I'll also need to write code to convert my DTO to a form bean and vice
versa.
I'm thinking we can lose the explicit form bean definition and the code which
converts between the DTO and form bean.

--- Mete Kural <[EMAIL PROTECTED]> wrote:
> >For a given form/action, the framework will be supplied with the FQCN of the
> >DTO/VO.  From there, it can determine what the fields of the form will be. 
> The
> >form bean validation/descriptor XML will provide the validation information
> and
> >any conversion rules as needed to format/parse between the value object and
> the
> >string representation for the form bean.
> 
> That sounds very interesting. I think there is interest in having support for
> dynamic forms where the fields of the form are determined dynamically rather
> than hardcoded in the JSP. What are the ideas on how to handle dynamic field
> names (and number of fields) in Struts 2.0? 
> 
> Let's say that we are designing a dynamic customer information editing form.
> Every user has different preferences on what fields they want to edit or
> allowed to edit. Action class accesses a web service and receives a SOAP
> response with exactly those fields that are fit for this user. How could Struts
> assemble the form dynamically and pre-populate the customer information and
> then validate it when the user submits?
> 
> Regards,
> Mete
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Mete Kural

>For a given form/action, the framework will be supplied with the FQCN of the
>DTO/VO.  From there, it can determine what the fields of the form will be.  The
>form bean validation/descriptor XML will provide the validation information and
>any conversion rules as needed to format/parse between the value object and the
>string representation for the form bean.

That sounds very interesting. I think there is interest in having support for dynamic 
forms where the fields of the form are determined dynamically rather than hardcoded in 
the JSP. What are the ideas on how to handle dynamic field names (and number of 
fields) in Struts 2.0? 

Let's say that we are designing a dynamic customer information editing form. Every 
user has different preferences on what fields they want to edit or allowed to edit. 
Action class accesses a web service and receives a SOAP response with exactly those 
fields that are fit for this user. How could Struts assemble the form dynamically and 
pre-populate the customer information and then validate it when the user submits?

Regards,
Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Hubert Rabago

--- Mete Kural <[EMAIL PROTECTED]> wrote:
> >FormBean is a concept 
> >(properties that map to form elements), plus this idea of XML as a 
> >FormBean. It could be a List or String or anything.
> 
> XML as a FormBean! That got my attention...
> 

What I would like to explore is the possibility of reusing existing DTOs/VOs in
the form beans.  Perhaps they (DTO/VO) won't be used to hold the form values
directly, but the framework can use them to determine the fields of the form. 
The framework can already interpret whether the input string is valid or not,
there's a good chance it'll only take a step or two more to let the framework
convert it to the right data type.
This will really reduce DRY violations between DTO/VO objects, form beans and
validation rule mappings.

For a given form/action, the framework will be supplied with the FQCN of the
DTO/VO.  From there, it can determine what the fields of the form will be.  The
form bean validation/descriptor XML will provide the validation information and
any conversion rules as needed to format/parse between the value object and the
string representation for the form bean.

I've been playing around with this idea for sometime now, and wouldn't mind
working on its code if there's interest in it.

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Mete Kural

>I am thinking of fliping sides on FormBean as interface, I am now 
>leaning against formbeans being an interface. FormBean is a concept 
>(properties that map to form elements), plus this idea of XML as a 
>FormBean. It could be a List or String or anything.

XML as a FormBean! That got my attention...

Say we want to populate customer information where a user can edit it like in an Excel 
spreadsheet. If the Action accesses a web service and receives a SOAP response and 
some XML objects in the SOAP response, sometimes it is too much processing to convert 
XML to Java objects if it is a lot of XML (for example: If the web service returns a 
list of 50 customers with detailed info). In such cases it may make more sense to do 
an XSLT transformation over the XML objects and render the form. Any suggestions on 
how this could be done in Struts 2.0?

Thanks,
Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)



Craig R. McClanahan wrote:

One of the things people have said they liked about using a chain to decompose
RequestProcessor is that you could easily compose your own chains, adding your
own custom processing stages and so on.  You can do exactly the same thing with
Filters by making each processXxx method its own filter, and using (say) the
request attributes to play the role of the Context object in commons-chain.
Filters have an additional capability if you're building a servlet-specific
framework -- they can wrap the actual request and response objects that are
passed on to the next filter in the chain, so you can implement some
interesting things not directly possible with a chain based implementation --
such as caching or on-the-fly compression of the response.


Craig
I do not get chains, but Hookom posted this link:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
which I sort of get (sort of) and it's my favoirte chain impl.

So if we can use filters or other chain, somone clever could write an 
"chainRequestProcessor" *interface*, that could be impledented for 
JSP2.0 filter... and then somone else could later write a JSP 1.2 
version, even non filter versions.

?

So I like chain as interface, and action as interface.

I am thinking of fliping sides on FormBean as interface, I am now 
leaning against formbeans being an interface. FormBean is a concept 
(properties that map to form elements), plus this idea of XML as a 
FormBean. It could be a List or String or anything. As long as it itself 
does not do DAO, and it maps to a form, good. (but do have way to unit 
test it w/o a container)
For starters so the JSTL x: tag can be used instead of c:out, plus some 
Stxx things.
(Then maybe a way to make HTML tag submit XML Doc, multi row and all).

.V





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> On Thu, 18 Dec 2003, Craig R. McClanahan wrote:
> 
> > Quoting Vic Cekvenich <[EMAIL PROTECTED]>:
> >
> > > Craig R. McClanahan wrote:
> > > >
> > > > Regarding 2.x, an important consideration will be base technology
> platforms
> > > --
> > > > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE
> 1.4
> > > (i.e.
> > > > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> > > > presentation technology, etc.).
> > > >
> > >
> > >
> > > JDK 1.4, yes.
> > >
> > > One popular? goal mentioned was:
> > > "Get away from reliance on Servlet API"
> > >
> > > I like being on Tomcat 4.
> > > What does it gain to be Tomcat 5 technically?
> >
> > For the portions of the framework that depend on Servlet 2.4, you get two
> > modest
> > but useful features:
> >
> > * Ability to execute filters on RequestDispatcher.include and
> >   RequestDispatcher.forward calls, which is not possible in 2.3.
> >   This gives you additional degrees of freedom in how you organize
> >   the processing logic of a framework like Struts -- for example,
> >   it would now be technically feasible to implement the controller
> >   as a filter instead of a servlet.
> 
> It would certainly be technically feasible to do that, but are there
> practical advantages to doing so? The only thing I can think of is that
> it's easy to punt on a request and let something else (i.e. another filter
> or a servlet) handle it, but I'm not sure why I would want to do that. Any
> good examples?
> 

One of the things people have said they liked about using a chain to decompose
RequestProcessor is that you could easily compose your own chains, adding your
own custom processing stages and so on.  You can do exactly the same thing with
Filters by making each processXxx method its own filter, and using (say) the
request attributes to play the role of the Context object in commons-chain.

Filters have an additional capability if you're building a servlet-specific
framework -- they can wrap the actual request and response objects that are
passed on to the next filter in the chain, so you can implement some
interesting things not directly possible with a chain based implementation --
such as caching or on-the-fly compression of the response.

> --
> Martin Cooper
> 

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Martin Cooper

On Thu, 18 Dec 2003, Craig R. McClanahan wrote:

> Quoting Vic Cekvenich <[EMAIL PROTECTED]>:
>
> > Craig R. McClanahan wrote:
> > >
> > > Regarding 2.x, an important consideration will be base technology platforms
> > --
> > > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4
> > (i.e.
> > > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> > > presentation technology, etc.).
> > >
> >
> >
> > JDK 1.4, yes.
> >
> > One popular? goal mentioned was:
> > "Get away from reliance on Servlet API"
> >
> > I like being on Tomcat 4.
> > What does it gain to be Tomcat 5 technically?
>
> For the portions of the framework that depend on Servlet 2.4, you get two
> modest
> but useful features:
>
> * Ability to execute filters on RequestDispatcher.include and
>   RequestDispatcher.forward calls, which is not possible in 2.3.
>   This gives you additional degrees of freedom in how you organize
>   the processing logic of a framework like Struts -- for example,
>   it would now be technically feasible to implement the controller
>   as a filter instead of a servlet.

It would certainly be technically feasible to do that, but are there
practical advantages to doing so? The only thing I can think of is that
it's easy to punt on a request and let something else (i.e. another filter
or a servlet) handle it, but I'm not sure why I would want to do that. Any
good examples?

--
Martin Cooper


>
> * Ability to define request lifecycle listeners (like the older
>   ones for session and application lifecycle) so you get a
>   complete and consistent event handling model.
>
> If your presentation tier is based on JSP 2.0 (instead of 1.1/1.2), you get a
> very large number of benefits.  The most visible ones are:
>
> * New ***much*** simpler API for building tag classes
>   (tag instance pooling is gone, single invocation method
>   instead of doStart/doEnd, ability to define a tag that
>   takes an arbitrary list of attributes, ...).
>
> * Tag files -- essentially, the ability to write a tag handler
>   using JSP code instead of Java, complete with parameter passing.
>
> * EL expressions evaluated everywhere (even template text),
>   so you don't need to limit yourself to just tags that implement
>   support for it (meaning we don't need struts-el variants).
>
>
>  What containers support
> > 2.4? How long for users to convert to the new 2.4 containers?
> > It'd be limiting.
> >
>
> The timing only matters when we're *done* with Struts 2.0, not now.  Based on
> our past history, I'd bet we're talking 12-18 months before a production
> quality release of 2.0 would be designed, developed, tested, and evolved to the
> point where we were happy enough to call it (and the APIs inside it) "stable."
>
> Because of how long it took for the J2EE 1.4 standards to go final (we were done
> with servlet and JSP last summer, but had to wait for the web services
> standards to go final), the various app server vendors are already well on the
> way towards 1.4 compliance. (Sun's certified server is already available, and
> is free for development AND production).  In the open source world, Tomcat 5
> already has production quality support, of course, and Jetty at least is not
> far behind (Greg is using Jasper2 for the JSP 2.0 stuff, so all he's got to do
> is catch up on the servlet 2.4 changes, which are pretty modest).
>
> > If it ends up being interface, so it could be even used from Soap or
> > applications (the discussed interface execute(Context ctx) ; ) it won't
> > matter much.
> >
>
> I agree that execute(Context ctx) is the right sort of method
> signature for the low level elements.  Come to think of it, that's already the
> signature used in commons-chain :-).
>
> > .V
> >
> > ps: I would like light IoC to be considered just a bit more as platform,
> > Pico, Oscar. Not Spring or Avalon.
> >
>
> All of these are interesting, but I think there's two levels of IoC that need to
> be thought about:
>
> * How the various pieces of Struts itself glue themselves together.
>
> * How application level services are composed and made available.
>
> It seems to me that different choices are possible at these two levels, and that
> (if different) the former should be lighter weight than the latter.  But we
> can't really pick particular technologies without having identified the needs
> and use cases first.
>
>
> Craig
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Joe Germuska <[EMAIL PROTECTED]>:

> I don't think I'm going to articulate this question very clearly, but 
> hopefully my drift will be gotten, so to speak.
> 
> If we're talking about making Struts independent of Servlets, then 
> what part of Struts would depend on either Servlet 2.3 or Servlet 2.4?
> 

Even if the core framework is independent of the presentation tier APIs, you
still need an adapter layer (often called a binding) between the particular
presentation API in use and the fundamental controller capabilities.  As I
pointed out in a previous message, I can see three very obvious bindings (to
servlets, to portlets, and to SOAP) that we'd undoubtedly want to include in
the basic package -- but we know we've succeeded when you can use the same
actions in each of those three environments (to perform the same transaction).

> Rather, how will we partition Struts so that we know our boundaries? 
> Presumably in a chain-like world, you could have Servlet 2.3 
> pre-processing chains and Servlet 2.4 pre-processing chains, and of 
> course we're going to have view post-processors for XSLT, Velocity... 
> so why shouldn't there be JSP 1.2 and JSP 2.0 post-processors?
> 

For servlet 2.3 versus 2.4, one approach to building frameworks would be to
architect the controller as a filter (or set of cooperating filters) rather
than as a servlet.  That is not a practical reality in servlet 2.3 because you
can't interpose filters on a RequestDispatcher call.

It's probably feasible to have a decomposed request processor that can be
implemented as either a set of filters (which, after all, is sort of the CoR
pattern again, just with different APIs) or as a servlet.  In practical terms,
though, it's easier to abstract the layers if we stick with a servlet as the
basic adapatation gadget.

The main reason I'm interested in J2EE 1.4 as the base platform is for JSP 2.0. 
But the choice between JSP 1.2 and JSP 2.0 should have zero impact on the
organization of the request processor -- it should be as totally an independent
decision as possible.  However, if you choose JSP 2.0 for the minimum platform
for JSP-based presentation stuff, you get servlet 2.4 for free to use in the
controller tier if you want.

> I suppose we ought to draft a glossary to make sure we all agree on 
> these various concepts...
> 
> Joe
> 

Craig





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Martin Cooper wrote:



I think I need to elaborate on my thoughts some more, since I wasn't
really clear the first time around...
A great deal has happened in web application framework land since Struts
came along 3-1/2 years ago. 
new technologies:
bytecode manipulation
IoC
SOA
filters
xml (XML Beans?)
AOP (just to list all)
Oscar
Unit Testing
scripting (including client javascript)
XML-RPC (not really new, just I like )
JDK 1.4 (interesting quirk: should jericko use the poor JDK logger? 
Maybe, but it's poor.)

Some can be leveraged... others do not apply.


So, what makes Struts Struts? What characteristics do we need to preserve
in order to keep it Struts, and retain the greatness that has made it so
amazingly popular? 
My answer is:
-light weight. If "jericho" is bloated, then IMO it fails.
-formbeans. The concept that bean properties correspond to a (html data 
entry) form. (thinking outside the box: maybe a XML Document that maps 
to form properties can also be a form bean in Jericho).
-it had several clear extension points
And what it did not have:
- A DAO. Many popular frameworks of the day went down with their DAO.

It was a minimalist framework, that did 80% of what you need and it did 
not get in the way when you wanted it to do things it was not designed for.

Therefore, one person needs to write most of Jericho over a single 
weekend and not try to please a committee, just their own business 
application and do initial check in! :-)

Lets not forget validation, btw. it should not be an after taught. Keep 
same? yes.



.V

"perfection is achived when you have nothing left to remove"
by Saint something or other


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Joe Germuska

I don't think I'm going to articulate this question very clearly, but 
hopefully my drift will be gotten, so to speak.

If we're talking about making Struts independent of Servlets, then 
what part of Struts would depend on either Servlet 2.3 or Servlet 2.4?

Rather, how will we partition Struts so that we know our boundaries? 
Presumably in a chain-like world, you could have Servlet 2.3 
pre-processing chains and Servlet 2.4 pre-processing chains, and of 
course we're going to have view post-processors for XSLT, Velocity... 
so why shouldn't there be JSP 1.2 and JSP 2.0 post-processors?

I suppose we ought to draft a glossary to make sure we all agree on 
these various concepts...

Joe

At 10:51 AM -0800 12/18/03, Craig R. McClanahan wrote:
For the portions of the framework that depend on Servlet 2.4, you get two
modest
but useful features:
* Ability to execute filters on RequestDispatcher.include and
  RequestDispatcher.forward calls, which is not possible in 2.3.
  This gives you additional degrees of freedom in how you organize
  the processing logic of a framework like Struts -- for example,
  it would now be technically feasible to implement the controller
  as a filter instead of a servlet.
* Ability to define request lifecycle listeners (like the older
  ones for session and application lifecycle) so you get a
  complete and consistent event handling model.
If your presentation tier is based on JSP 2.0 (instead of 1.1/1.2), you get a
very large number of benefits.  The most visible ones are:
* New ***much*** simpler API for building tag classes
  (tag instance pooling is gone, single invocation method
  instead of doStart/doEnd, ability to define a tag that
  takes an arbitrary list of attributes, ...).
* Tag files -- essentially, the ability to write a tag handler
  using JSP code instead of Java, complete with parameter passing.
* EL expressions evaluated everywhere (even template text),
  so you don't need to limit yourself to just tags that implement
  support for it (meaning we don't need struts-el variants).


--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
 "We want beef in dessert if we can get it there."
  -- Betty Hogan, Director of New Product Development, National 
Cattlemen's Beef Association

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Vic Cekvenich <[EMAIL PROTECTED]>:

> Craig R. McClanahan wrote:
> > 
> > Regarding 2.x, an important consideration will be base technology platforms
> --
> > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4
> (i.e.
> > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> > presentation technology, etc.).
> > 
> 
> 
> JDK 1.4, yes.
> 
> One popular? goal mentioned was:
> "Get away from reliance on Servlet API"
> 
> I like being on Tomcat 4.
> What does it gain to be Tomcat 5 technically?

For the portions of the framework that depend on Servlet 2.4, you get two
modest
but useful features:

* Ability to execute filters on RequestDispatcher.include and
  RequestDispatcher.forward calls, which is not possible in 2.3.
  This gives you additional degrees of freedom in how you organize
  the processing logic of a framework like Struts -- for example,
  it would now be technically feasible to implement the controller
  as a filter instead of a servlet.

* Ability to define request lifecycle listeners (like the older
  ones for session and application lifecycle) so you get a
  complete and consistent event handling model.

If your presentation tier is based on JSP 2.0 (instead of 1.1/1.2), you get a
very large number of benefits.  The most visible ones are:

* New ***much*** simpler API for building tag classes
  (tag instance pooling is gone, single invocation method
  instead of doStart/doEnd, ability to define a tag that
  takes an arbitrary list of attributes, ...).

* Tag files -- essentially, the ability to write a tag handler
  using JSP code instead of Java, complete with parameter passing.

* EL expressions evaluated everywhere (even template text),
  so you don't need to limit yourself to just tags that implement
  support for it (meaning we don't need struts-el variants).

 What containers support 
> 2.4? How long for users to convert to the new 2.4 containers?
> It'd be limiting.
> 

The timing only matters when we're *done* with Struts 2.0, not now.  Based on
our past history, I'd bet we're talking 12-18 months before a production
quality release of 2.0 would be designed, developed, tested, and evolved to the
point where we were happy enough to call it (and the APIs inside it) "stable."

Because of how long it took for the J2EE 1.4 standards to go final (we were done
with servlet and JSP last summer, but had to wait for the web services
standards to go final), the various app server vendors are already well on the
way towards 1.4 compliance. (Sun's certified server is already available, and
is free for development AND production).  In the open source world, Tomcat 5
already has production quality support, of course, and Jetty at least is not
far behind (Greg is using Jasper2 for the JSP 2.0 stuff, so all he's got to do
is catch up on the servlet 2.4 changes, which are pretty modest).

> If it ends up being interface, so it could be even used from Soap or 
> applications (the discussed interface execute(Context ctx) ; ) it won't 
> matter much.
> 

I agree that execute(Context ctx) is the right sort of method
signature for the low level elements.  Come to think of it, that's already the
signature used in commons-chain :-).

> .V
> 
> ps: I would like light IoC to be considered just a bit more as platform, 
> Pico, Oscar. Not Spring or Avalon.
> 

All of these are interesting, but I think there's two levels of IoC that need to
be thought about:

* How the various pieces of Struts itself glue themselves together.

* How application level services are composed and made available.

It seems to me that different choices are possible at these two levels, and that
(if different) the former should be lighter weight than the latter.  But we
can't really pick particular technologies without having identified the needs
and use cases first.

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Martin Cooper wrote:
A great deal has happened in web application framework land since Struts
came along 3-1/2 years ago. There is a boatload of frameworks out there
now, and some of them have some great ideas. What I don't really want to
end up with is a Struts 2.0 that is simply a reinvention of what other
people have done, with a compatibility layer to make it accessible to
Struts 1.x developers.
So, what makes Struts Struts? What characteristics do we need to preserve
in order to keep it Struts, and retain the greatness that has made it so
amazingly popular? How far can we go before the decision to choose Struts
2.0, or not, is no different to a potential developer than the decision to
chose any one of the other frameworks out there today? Obviously,
compatibility is going to be very important, but I hope that's not all!
I think that's going to come down to "I know it when I see it".

I'd say that Struts (or any framework) is an aggregation of its 
components. In Struts 1.0, we had mainly Form, Forward, Mapping, Action, 
and Messaging components. In Struts 1.1, we added Exception, Validation, 
Composite (or Tile), and PlugIn components.

So long as Struts 2.x retains the same hallmark components in a 
recognizable form, I'd say it's still Struts.

And, so far, I haven't heard anyone suggest anything that couldn't also 
be implemented in Struts 1.x over time. It's just that deprecation and 
migration can be a painful process, and sometimes it's better to bite 
the bullet and tell people that they might have to change this or that 
if they want to migrate now.

We've all admitted several times that we would-a could-a done things 
differently if we knew then what we know now. All anyone is saying is 
that now is the time to fix the would-a and could-a's.

I don't know about anyone else, but I'm sorta planning on spending yet 
another twenty years writing business applications, and this seems like 
a very good time to try and write the best Struts framework we can, and 
make my declining years easier to bear :)

Of course, the important thing will be for whoever is working on a 
Struts 2.x implementation to "eat our own dog food", like we had to do 
for Struts 1.x. If it doesn't work for us, it's surely not going to work 
for anyone else.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>:
[snip]
> > 
> > Although it's not evident from the Jericho DTD, the intention 
> > is to use 
> > a Context object in the signatures, perhaps the Commons Chain 
> > Context, 
> > so as to encapsulate Servlet/Portlet dependencies.
> > 
> 
> So you no longer going to pass in request and response objects
> around, but instead have a context instead. Maybe it would
> be a little inconvenient for every Action to call 
> ``context.getRequest()'' all the time. Perhaps we can keep them
> please. I dont mind losing the form bean. I could live with
> ``context.getForm()'', because for some environments you dont
> need to buffer a user's input. e.g. web services, or even 
> a flat file.
> 
> public ActionForward someStateAction( 
>   org.apache.commons.chain.Context  context,
>   some.generic.request  request,
>   some.generic.response response );
> 
> And for those of us who have subclassed Action, and ActionForm
> to create our own super frameworks, this will be very
> interesting and involved work to say the least/.
> 

If you're going to call context.getRequest() at all, then I think you're losing
most of the benefits of abstracting away the servlet APIs - if you want to be
able to reuse "actions" in the business tier then there *is* no such thing as a
request.  Instead, it would be better for a particular Command (for purposes of
this discussion, I'm assuming we use something like commons-chain as the
plumbing so I use that terminology; it would need to be translated for a
different low level API but the concepts sare still the same) that represents
the concept of an "action" to presume that some previous commands in the chain
have already pulled the presentation tier specific data out of whatever
"request" objects there were, and made it available as context attributes of
the appropriate (framework-specific) types.

For example, assume we created an abstraction of a form (what is now ActionForm)
to represent incoming data from the user.  Copying request parameters into this
abstract form thingie would be the job of a command very early in the chain. 
It's easy to imagine at least three commonly used lead-in actions:

* One that pulls request parameters from an HttpServletRequest (servlet api)

* One that pulls request parameters from a PortletRequest (portlet api)

* One that pulls request parameters from a SOAP request

The key value-add is that, once the lead-in command has performed this
transition for you, no further commands ever need to know that there *was* such
a thing as a "request".  Those commands would never call getRequest(), because
they don't care how the "form thingie" got there; it contains everything they
need to perform their tasks.  Therefore, you can reuse the processing command
in new and interesting ways -- just to whet the appetite, consider:

* In a unit test, where the test case synthesizes a "form thingie"
  with known contents, calls the processing logic, and ensures that
  the correct state changes happened.  No real "request" ever exists.

* In an integration app, where you want to have changes made in
  an existing application also affect data in a separate app.  One
  way to do that would be to synthesize more than one "form" from
  the same actual user input, and do all the necessary updates.
  The business logic for any single transaction has no need to know
  that it's being used in this new way.

* In a batch application (or a messaging appication, or ...) where
  the incoming data is acquired from data files rather than users,
  but you want the same sorts of state changes in your back-end systems.

The hard part (in terms of designing the framework) is to understand how to
factor the reusable concepts, and then what to name them -- on that topic, for
example, even the name "form thingie" might be a little bit to constraining
when imagining how the basic idea can be used in more than one context.

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Martin Cooper

On Thu, 18 Dec 2003, Craig R. McClanahan wrote:

> Quoting Martin Cooper <[EMAIL PROTECTED]>:
>
> > Just to add a few more off the top of my head:
> >
> > * Make the Struts core independent of the Servlets spec and the Portlets
> > spec, so that it can be used for both, and more.
> >
> > * Separate view-technology-specific code into separate components, so that
> > the core is view-technology agnostic. So, for example, all JSP specific
> > code, including all of the taglibs, would move to a JSP component.
> >
> > * Rework Tiles into two facets, so that the core is independent of the
> > Servlets spec and JSP, and the JSP component is part of the view specific
> > component described above.
> >
> > * Split out file upload handling into a separate pluggable component, with
> > its own configuration. I noticed that this is still in the initial Jericho
> > DTD, but I think it should not be. The file upload implementation is
> > pluggable, and so should be able to have its own config definition.
> >
> > I know I have more in notes at home, but just wanted to throw these out.
> >
> > A sort of meta-question: When is Struts no longer Struts? I mean, how much
> > change can we introduce in Struts 2.0 before it becomes so different that
> > it's really a different framework? Do we need to decide on what Struts is,
> > and is not, before we go too far down the path of Struts 2.0? Or do we let
> > whatever falls out just fall out and deal with it later?
> >
>
> Product names are marketing, not technology.  Struts 2.0 will be Struts if *we*
> call it Struts :-).
>
> More seriously, the amount of change between major product versions can be
> pretty enormous in some cases (ask classic ASP developers if they think ASP.NET
> is really the same environment or not).  Innovation and revolution are
> perfectly fine things to do (applying all the lessons we've learned along the
> way), but we should also remember that there are thousands of apps based on a
> Struts 1.x architecture that need continuing support.  We need to have the
> discipline to continue to work evolving a 1.2.x world while we're creating a
> new 2.x one.

I think I need to elaborate on my thoughts some more, since I wasn't
really clear the first time around...

A great deal has happened in web application framework land since Struts
came along 3-1/2 years ago. There is a boatload of frameworks out there
now, and some of them have some great ideas. What I don't really want to
end up with is a Struts 2.0 that is simply a reinvention of what other
people have done, with a compatibility layer to make it accessible to
Struts 1.x developers.

So, what makes Struts Struts? What characteristics do we need to preserve
in order to keep it Struts, and retain the greatness that has made it so
amazingly popular? How far can we go before the decision to choose Struts
2.0, or not, is no different to a potential developer than the decision to
chose any one of the other frameworks out there today? Obviously,
compatibility is going to be very important, but I hope that's not all!

>
> Regarding 2.x, an important consideration will be base technology platforms --
> I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e.
> Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> presentation technology, etc.).

+1 to a J2EE baseline.

--
Martin Cooper


>
> > --
> > Martin Cooper
> >
>
> Craig
>
>
> >
> > On Wed, 17 Dec 2003, Don Brown wrote:
> >
> > > Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> > > release work. :)  I'll throw out some ideas here, then develop them later
> > > in the wiki:
> > >
> > > - Make Inversion of Control central.  By using an IoC framework to wire
> > > Struts together, it makes it really easy to extend or improve Struts not
> > > only for future development but for users as well.  I'd recommend Spring's
> > > IoC impl as it is small (>100k), really easy to use, and easily
> > > extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
> > > frameworks that let you plug in Pico/Spring/Avalon, etc.
> > >
> > > - Use XML Schema over DTD's.  Give struts config its own default namespace
> > > to make it easier for users to mix in elements of other namespaces.  An
> > > example would be adding custom documentation attributes and elements.  Of
> > > course the usual arguments for XML Schema over DTD's apply as well.
> > >
> > > - Replace paths with URL's, allowing for a default protocol.  An action
> > > path would look like "action://foo" or a tiles forward would be
> > > "tiles://tilesdef"  This would make it easy to plug in handlers to support
> > > different presentation engines.  If no protocol is specified, the path is
> > > handled as usual.
> > >
> > > - As Ted said, contine with the wildcard theme.  Struts should do
> > > everything possible to cut down configuration.
> > >
> > > - Also, again totally agreeing with Ted, make everything interface based,
> > > have defaul

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Craig R. McClanahan wrote:
Regarding 2.x, an important consideration will be base technology platforms --
I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e.
Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
presentation technology, etc.).


JDK 1.4, yes.

One popular? goal mentioned was:
"Get away from reliance on Servlet API"
I like being on Tomcat 4.
What does it gain to be Tomcat 5 technically? What containers support 
2.4? How long for users to convert to the new 2.4 containers?
It'd be limiting.

If it ends up being interface, so it could be even used from Soap or 
applications (the discussed interface execute(Context ctx) ; ) it won't 
matter much.

.V

ps: I would like light IoC to be considered just a bit more as platform, 
Pico, Oscar. Not Spring or Avalon.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> Just to add a few more off the top of my head:
> 
> * Make the Struts core independent of the Servlets spec and the Portlets
> spec, so that it can be used for both, and more.
> 
> * Separate view-technology-specific code into separate components, so that
> the core is view-technology agnostic. So, for example, all JSP specific
> code, including all of the taglibs, would move to a JSP component.
> 
> * Rework Tiles into two facets, so that the core is independent of the
> Servlets spec and JSP, and the JSP component is part of the view specific
> component described above.
> 
> * Split out file upload handling into a separate pluggable component, with
> its own configuration. I noticed that this is still in the initial Jericho
> DTD, but I think it should not be. The file upload implementation is
> pluggable, and so should be able to have its own config definition.
> 
> I know I have more in notes at home, but just wanted to throw these out.
> 
> A sort of meta-question: When is Struts no longer Struts? I mean, how much
> change can we introduce in Struts 2.0 before it becomes so different that
> it's really a different framework? Do we need to decide on what Struts is,
> and is not, before we go too far down the path of Struts 2.0? Or do we let
> whatever falls out just fall out and deal with it later?
> 

Product names are marketing, not technology.  Struts 2.0 will be Struts if *we*
call it Struts :-).

More seriously, the amount of change between major product versions can be
pretty enormous in some cases (ask classic ASP developers if they think ASP.NET
is really the same environment or not).  Innovation and revolution are
perfectly fine things to do (applying all the lessons we've learned along the
way), but we should also remember that there are thousands of apps based on a
Struts 1.x architecture that need continuing support.  We need to have the
discipline to continue to work evolving a 1.2.x world while we're creating a
new 2.x one.

Regarding 2.x, an important consideration will be base technology platforms --
I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e.
Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
presentation technology, etc.).

> --
> Martin Cooper
> 

Craig


> 
> On Wed, 17 Dec 2003, Don Brown wrote:
> 
> > Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> > release work. :)  I'll throw out some ideas here, then develop them later
> > in the wiki:
> >
> > - Make Inversion of Control central.  By using an IoC framework to wire
> > Struts together, it makes it really easy to extend or improve Struts not
> > only for future development but for users as well.  I'd recommend Spring's
> > IoC impl as it is small (>100k), really easy to use, and easily
> > extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
> > frameworks that let you plug in Pico/Spring/Avalon, etc.
> >
> > - Use XML Schema over DTD's.  Give struts config its own default namespace
> > to make it easier for users to mix in elements of other namespaces.  An
> > example would be adding custom documentation attributes and elements.  Of
> > course the usual arguments for XML Schema over DTD's apply as well.
> >
> > - Replace paths with URL's, allowing for a default protocol.  An action
> > path would look like "action://foo" or a tiles forward would be
> > "tiles://tilesdef"  This would make it easy to plug in handlers to support
> > different presentation engines.  If no protocol is specified, the path is
> > handled as usual.
> >
> > - As Ted said, contine with the wildcard theme.  Struts should do
> > everything possible to cut down configuration.
> >
> > - Also, again totally agreeing with Ted, make everything interface based,
> > have default implementations, and free apps of HTTP.  Ideally, I'd like to
> > see extra effort going into making it easy if not effortless to take a
> > Struts 2.0 app and use the code in a portlet or web service environment.
> > At least in my area, clients are wanting human and machine interfaces,
> > with the human interface generally being behind a portal.
> >
> > Anyways, those are my "brainstorming" thoughts.  If any look interesting,
> > I'll write something up in the wiki.
> >
> > Don
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-18 Thread Martin Cooper

On Wed, 17 Dec 2003, Don Brown wrote:

> Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> release work. :)  I'll throw out some ideas here, then develop them later
> in the wiki:
>
> - Make Inversion of Control central.  By using an IoC framework to wire
> Struts together, it makes it really easy to extend or improve Struts not
> only for future development but for users as well.  I'd recommend Spring's
> IoC impl as it is small (>100k), really easy to use, and easily
> extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
> frameworks that let you plug in Pico/Spring/Avalon, etc.

I'm a little hesitant to start depending on other frameworks. It's not
that I think they don't have anything to offer us, it's just what it does
to the newcomer to Struts. If someone has to learn Struts *and* Spring
(for example) to get going, then we've set the bar much higher.

If we do end up deciding to depend on something like this, I believe we'll
need to put in the work to make it "look" like Struts. Taking Spring as an
example again, the substantial difference in the "character" of the XML
config files would easily confuse a newcomer trying to get his/her head
around the syntax. If we could make those files "look" like Struts config
files (or vice versa, for that matter), that would help, though.

--
Martin Cooper


>
> - Use XML Schema over DTD's.  Give struts config its own default namespace
> to make it easier for users to mix in elements of other namespaces.  An
> example would be adding custom documentation attributes and elements.  Of
> course the usual arguments for XML Schema over DTD's apply as well.
>
> - Replace paths with URL's, allowing for a default protocol.  An action
> path would look like "action://foo" or a tiles forward would be
> "tiles://tilesdef"  This would make it easy to plug in handlers to support
> different presentation engines.  If no protocol is specified, the path is
> handled as usual.
>
> - As Ted said, contine with the wildcard theme.  Struts should do
> everything possible to cut down configuration.
>
> - Also, again totally agreeing with Ted, make everything interface based,
> have default implementations, and free apps of HTTP.  Ideally, I'd like to
> see extra effort going into making it easy if not effortless to take a
> Struts 2.0 app and use the code in a portlet or web service environment.
> At least in my area, clients are wanting human and machine interfaces,
> with the human interface generally being behind a portal.
>
> Anyways, those are my "brainstorming" thoughts.  If any look interesting,
> I'll write something up in the wiki.
>
> Don
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

PILGRIM, Peter, FM wrote:
This is early days, and too-low level so I 'd put this point
on the back burner. 
We've started to track suggestions like these here:

http://cvs.apache.org/viewcvs.cgi/jakarta-struts/contrib/struts-jericho/

to help avoid recovering the same ground.

Of course, what's on the roadmap for Struts 2.0.x still goes as well.

http://jakarta.apache.org/struts/status.html

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)


public ActionForward someStateAction( 
 org.apache.commons.chain.Context  context,
 some.generic.request  request,
 some.generic.response response );




Why not just KISS and
 public ActionForward someStateAction(
   org.apache.commons.chain.Context  context );
It can *all* go into context(or a Map!!!), else we have the 
tilesAction 
execute signature.

I can allways do a
map.get("request")
This would work for SOAP or other protocols.

.V


Yes I agree KISS is better, Vic. It is better by the design.
Maybe you can be person to announce to the Struts 1.0
1.1 user base that all of their Actions are now invalid, they 
wont compile for Struts 2.0 because you need to upgrade ALL 
your state methods to get HttpServletRequest and 
HttpServletResponse and ActionForm and ActionMapping 
from the Chains context.

Both above method signatures above are not compatible!

But you could have a base class:

execute(context) {
execute(context.getReq(),context.getMapp(),...
}
You could go the other way too, not at the same time

execte(req,resp,mapping,the4ththing) {
context = new Context();
context.setReq(req);
context.setMapping(mappping);
execute(context);
}
This is sort of what I do now in bP
So it can be compatible.
Beside, we had perform and excute once, so users know.
Also, I imagine a long road to 2.0, people will be using nightly build 
for a while that only has the new stuff.

.V



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)


> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich

====

> 
> >  public ActionForward someStateAction(
> >org.apache.commons.chain.Context  context );
> > 
> > 
> > It can *all* go into context(or a Map!!!), else we have the 
> tilesAction 
> > execute signature.
> > 
> > I can allways do a
> > map.get("request")
> > 
> > This would work for SOAP or other protocols.
> > 
> 
> 
> I was going to add:
> This lets people "store" and pass additional info.
> Else they start putting properties in action (not thread safe).
> 
> Maybe Struts 2.0 should have an action implemenation that gets 
> instaciated every user session (it should not be used but... 
> it exposes 
> the issue).
> 
> 
> .V
> 

If you look Commons Chain then you will that the ``Context'' 
(or it at least its concrete implementation ``ContextImpl'') is 
a `java.util.HashMap' subclass.

--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923


***
The Royal Bank of Scotland plc. Registered in Scotland No 90312.   Registered 
Office: 36 St Andrew Square, Edinburgh EH2 2YB.  
Authorised and regulated by the Financial Services Authority 
 
This e-mail message is confidential and for use by the  
addressee only. If the message is received by anyone other 
than the addressee, please return the message to the sender  
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The   
Royal Bank of Scotland plc does not accept responsibility for  
changes made to this message after it was sent.  
   
 
Whilst all reasonable care has been taken to avoid the   
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its   
systems or data.  No responsibility is accepted by The Royal   
Bank of Scotland plc in this regard and the recipient should carry   
out such virus and other checks as it considers appropriate.   
   
Visit our websites at: 
 
http://www.rbs.co.uk/CBFM
http://www.rbsmarkets.com 
   




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)


> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich
> 
> 
> >>In terms of new functionality, the three biggest fish I'd 
> like to fry 
> >>are Workflow, SSL, and Unit Testing. Towards that end, I'd like to 
> >>consider integrating LivingLogic's Workflow, ssl-ext, and Struts 
> >>TestCase into the Struts 2.x development stream. We may 
> also want to 
> >>consider adding these as standard options to Struts 1.x, so 
> >>as to blaze 
> >>a trail.
> > 
> > 
> 
> I aqgree that DAO should be outside of Sturts.
> I do not think Workflow should be inside. Becuase I do not 
> think it is a 
> good practice. It may be needed by some people... as a plug in.
>

Struts greatest strength up to now is its agnostic data model feel.
You need to supply the Model architecture, so I agree there.
It has also been historically a weakness where users have been
a little confused by form bean and data transfer objects.
Ie the various ways of streaming information back and forth
the tier.
 
> 
> > Integrating StrutsTestCase would help with the Unit tests,
> > although it will have to be heavily modified in parallel
> > to keep up with changes in development. 
> > 
> 
> I also do not think testing should be insdide. There are many 
> that look 
> into JVM, into container's JSP, etc. and people should inovate.
> I use OpenSTA, becuase I want to see what happens under load.
> 

Au contraire. I think it would be benefit the framework if there
was a standard Strut's unit test part available out-of-the-box.
It would aid developer's writing containerless unit tests,
otherwise it is down the road with Cactus. Nope. Strike that
 StrutsTestCase does support Cactus. Whatever the framework
should have unit test of its own delivered whether it is
Struts Test Case or self-amogrified hand crafted 
``junit.framework.TestCase'' subclass.

> However... Monitoring and Managing the application while runing in 
> production maybe should be included. Ex: Jamon.
> I used it, and it's great.
> I works similar to log4j.
> Or at least it should be documented.
> In days of ClientServer, 3 tier ment:
> Data Layer, Presentation Layer and Managment Layer.
> 

You could add this feature on with JMX and MBean and write 
a ``ComposableRequestProcessor'' , I mean special Command to
monitor the processor flow. Perhaps you can write an instrumented
`org.apache.commons.chain.Chain implementation' that is JMX
compatible.

> > 
> > So you no longer going to pass in request and response objects
> > around, but instead have a context instead. Maybe it would
> > be a little inconvenient for every Action to call 
> > ``context.getRequest()'' all the time. Perhaps we can keep them
> > please. I dont mind losing the form bean. I could live with
> > ``context.getForm()'', because for some environments you dont
> > need to buffer a user's input. e.g. web services, or even 
> > a flat file.
> > 
> > public ActionForward someStateAction( 
> >   org.apache.commons.chain.Context  context,
> >   some.generic.request  request,
> >   some.generic.response response );
> > 
> >
> 
> 
> Why not just KISS and
>   public ActionForward someStateAction(
> org.apache.commons.chain.Context  context );
> 
> 
> It can *all* go into context(or a Map!!!), else we have the 
> tilesAction 
> execute signature.
> 
> I can allways do a
> map.get("request")
> 
> This would work for SOAP or other protocols.
> 
> .V

Yes I agree KISS is better, Vic. It is better by the design.
Maybe you can be person to announce to the Struts 1.0
1.1 user base that all of their Actions are now invalid, they 
wont compile for Struts 2.0 because you need to upgrade ALL 
your state methods to get HttpServletRequest and 
HttpServletResponse and ActionForm and ActionMapping 
from the Chains context.

This is early days, and too-low level so I 'd put this point
on the back burner. It can be easily solved using Java Reflection.

--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923


***
The Royal Bank of Scotland plc. Registered in Scotland No 90312.  Registered Office: 
36 St Andrew Square, Edinburgh EH2 2YB.  
Authorised and regulated by the Financial Services Authority 
 
This e-mail message is confidential and for use by the  
addressee only. If the message is received by anyone other 
than the addressee, please return the message to the sender  
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The   
Royal Bank of Scotland plc does not accept responsibility for  
changes made to this message after it was sent.  
   
 
Whilst all reasonable care has been taken

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)


 public ActionForward someStateAction(
   org.apache.commons.chain.Context  context );
It can *all* go into context(or a Map!!!), else we have the tilesAction 
execute signature.

I can allways do a
map.get("request")
This would work for SOAP or other protocols.



I was going to add:
This lets people "store" and pass additional info.
Else they start putting properties in action (not thread safe).
Maybe Struts 2.0 should have an action implemenation that gets 
instaciated every user session (it should not be used but... it exposes 
the issue).

.V



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)


In terms of new functionality, the three biggest fish I'd like to fry 
are Workflow, SSL, and Unit Testing. Towards that end, I'd like to 
consider integrating LivingLogic's Workflow, ssl-ext, and Struts 
TestCase into the Struts 2.x development stream. We may also want to 
consider adding these as standard options to Struts 1.x, so 
as to blaze 
a trail.


I aqgree that DAO should be outside of Sturts.
I do not think Workflow should be inside. Becuase I do not think it is a 
good practice. It may be needed by some people... as a plug in.


Integrating StrutsTestCase would help with the Unit tests,
although it will have to be heavily modified in parallel
to keep up with changes in development. 

I also do not think testing should be insdide. There are many that look 
into JVM, into container's JSP, etc. and people should inovate.
I use OpenSTA, becuase I want to see what happens under load.

However... Monitoring and Managing the application while runing in 
production maybe should be included. Ex: Jamon.
I used it, and it's great.
I works similar to log4j.
Or at least it should be documented.
In days of ClientServer, 3 tier ment:
Data Layer, Presentation Layer and Managment Layer.

So you no longer going to pass in request and response objects
around, but instead have a context instead. Maybe it would
be a little inconvenient for every Action to call 
``context.getRequest()'' all the time. Perhaps we can keep them
please. I dont mind losing the form bean. I could live with
``context.getForm()'', because for some environments you dont
need to buffer a user's input. e.g. web services, or even 
a flat file.

public ActionForward someStateAction( 
  org.apache.commons.chain.Context  context,
  some.generic.request  request,
  some.generic.response response );




Why not just KISS and
 public ActionForward someStateAction(
   org.apache.commons.chain.Context  context );
It can *all* go into context(or a Map!!!), else we have the tilesAction 
execute signature.

I can allways do a
map.get("request")
This would work for SOAP or other protocols.

.V



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)


The BeanWrapper and the BeanFactory are interesting ideas.
An example of configuring commons DBCP is given
http://www.springframework.org/docs/lightweight_container.html
I am not convince however of the requirement for BeanFactory.
I can understand if you need to have massive XML configuration
and need to dynamic generate Beans (objects) at run-time.
It is great but other than that I can really view to the
advantage inverse of control there that Struts or Commons BeanUtils
combine Digester could not do itself.
I like this for beans:
www.joda.org
Wow!
It would get rid of a lot of questions on the user list.
(This man wanted to go ASF)
Struts is great because it concentrates on doing one thing well MVC.
I wouldn't want it to branch out go into a generic framework space
e.g Avalon, Expresso, Keel, Spring, Pico etc.
But maybe  build Struts on top of Pico or similar 
(http://oscar-osgi.sourceforge.net) or hivemind or...

See if we pick high level light interfaces and use "generic" jars like 
now, it could be done quick like, and fund, since code would be done at 
a bit higher level.

(And maybe WebWork or Spring or  implement our MVC high level light 
interface.)

.V



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: 17 December 2003 23:00
> To: Struts Developers List
> Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
> 
====
> 
> > A sort of meta-question: When is Struts no longer Struts? I 
> mean, how much
> > change can we introduce in Struts 2.0 before it becomes so 
> different that
> > it's really a different framework? Do we need to decide on 
> what Struts is,
> > and is not, before we go too far down the path of Struts 
> 2.0? Or do we let
> > whatever falls out just fall out and deal with it later?
> 
> Legally, I'd say that Strut is whatever the Struts Community 
> says it is. 
> It's a brand that belongs to the ASF, which we manage on the 
> Foundation's behalf.
> 
> Technically, I'd say that Struts (or any framework) is an 
> aggregation of 
> its components. In Struts 1.0, we had mainly Form, Forward, Mapping, 
> Action, and Messaging components. In Struts 1.1, we added Exception, 
> Validation, Composite (or Tile), and PlugIn components.
> 
> So long as Struts 2.x retains the same hallmark components in a 
> recognizable form, I'd say it's still Struts. :)
> 
> Overall, it's my feeling that Struts does all the right things, it's 
> just that we don't do them in all the right places. :) Being able to 
> extend elements is one example. Encapsulating paths is another.
> 
> My own goal for Struts 2.x is to consistently apply all our best 
> practices and eliminate inconsistent and legacy practices. 
> We've got a 
> good thing here; we just need to make it even better. :)
> 
> In terms of new functionality, the three biggest fish I'd like to fry 
> are Workflow, SSL, and Unit Testing. Towards that end, I'd like to 
> consider integrating LivingLogic's Workflow, ssl-ext, and Struts 
> TestCase into the Struts 2.x development stream. We may also want to 
> consider adding these as standard options to Struts 1.x, so 
> as to blaze 
> a trail.

Integrating StrutsTestCase would help with the Unit tests,
although it will have to be heavily modified in parallel
to keep up with changes in development. 

> 
> Although it's not evident from the Jericho DTD, the intention 
> is to use 
> a Context object in the signatures, perhaps the Commons Chain 
> Context, 
> so as to encapsulate Servlet/Portlet dependencies.
> 

So you no longer going to pass in request and response objects
around, but instead have a context instead. Maybe it would
be a little inconvenient for every Action to call 
``context.getRequest()'' all the time. Perhaps we can keep them
please. I dont mind losing the form bean. I could live with
``context.getForm()'', because for some environments you dont
need to buffer a user's input. e.g. web services, or even 
a flat file.

public ActionForward someStateAction( 
  org.apache.commons.chain.Context  context,
  some.generic.request  request,
  some.generic.response response );

And for those of us who have subclassed Action, and ActionForm
to create our own super frameworks, this will be very
interesting and involved work to say the least/.

> -Ted.
> 

--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923


***
The Royal Bank of Scotland plc. Registered in Scotland No 90312.   Registered 
Office: 36 St Andrew Square, Edinburgh EH2 2YB.  
Authorised and regulated by the Financial Services Authority 
 
This e-mail message is confidential and for use by the  
addressee only. If the message is received by anyone other 
than the addressee, please return the message to the sender  
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The   
Royal Bank of Scotland plc does not accept responsibility for  
changes made to this message after it was sent.  
   
 
Whilst all reasonable care has been taken to avoid the   
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its   
systems or data.  No responsibility is accepted by The Royal   
Bank of Scotland plc in this regard and the recipient should carry   
out such virus and other checks as it considers appropriate.

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

David Graham wrote:
--- Vic Cekvenich <[EMAIL PROTECTED]> wrote:

And even a simple DAO interface, to be used optionaly be people, so 
they can go back and forth from iBatis to Hibreante or what ever.


I started the Mapper project in the commons for this exact reason.  It
doesn't belong in Struts.


+1

Struts should remain a BYOM (Bring Your Own Model) framework. As soon as 
we include *anything* along these lines, people perceive it as the 
preferred way of doing things. (Look at what happened with 
GenericDataSource).

Certainly, we can include more HOWTOs in the documentation about hooking 
Struts up with various business and persistence layers.  But the classes 
for doing this should not live under the Struts brand..


http://jakarta.apache.org/commons/sandbox/mapper/

David




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)


> -Original Message-
> From: Sgarlata Matt [mailto:[EMAIL PROTECTED]
> Sent: 17 December 2003 22:11
> To: Struts Developers List
> Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
> 
> 
> - Original Message - 
> From: "Joe Germuska" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Wednesday, December 17, 2003 5:04 PM
> Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
> 
> 
> > So then, with specific frameworks,  I don't understand how Pico's
> > orientation towards constructors works in an environment where beans
> > need to be dynamically instantiated, but perhaps I just haven't
> > thought about it hard enough.  Avalon seems too heavy, which leaves
> > us (or me at least) with Spring and HiveMind.  I haven't developed
> > with either but so far the docs for Spring give me a warm fuzzy
> > feeling while the HiveMind docs kind of scare me.
> 
> I agree with your assessment of frameworks 100%.  However, 
> Spring is under
> an LGPL license, so Struts can't use Spring unless either 
> Struts switches to
> LGPL or Spring switches to ASF, right?  It would be kind of 
> silly for Struts
> to stay under ASF in this case, since the Spring license 
> would force the
> undesirable LGPL clauses on any projects that were based on 
> Struts.  Am I
> right?
> 
> Matt
What kind of Spring Framework classes would you want to use in 
Struts 2.0?

The BeanWrapper and the BeanFactory are interesting ideas.
An example of configuring commons DBCP is given
http://www.springframework.org/docs/lightweight_container.html

I am not convince however of the requirement for BeanFactory.
I can understand if you need to have massive XML configuration
and need to dynamic generate Beans (objects) at run-time.
It is great but other than that I can really view to the
advantage inverse of control there that Struts or Commons BeanUtils
combine Digester could not do itself.

Struts is great because it concentrates on doing one thing well MVC.
I wouldn't want it to branch out go into a generic framework space
e.g Avalon, Expresso, Keel, Spring, Pico etc.

The major design difficulties are abstract away the request and response
objects from the controller actions, and also configuration of any
other front-end objects you need along the way. To a certain extent 
Commons Chain and its context leads the way regarding the former.

--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923


***
The Royal Bank of Scotland plc. Registered in Scotland No 90312.   Registered 
Office: 36 St Andrew Square, Edinburgh EH2 2YB.  
Authorised and regulated by the Financial Services Authority 
 
This e-mail message is confidential and for use by the  
addressee only. If the message is received by anyone other 
than the addressee, please return the message to the sender  
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The   
Royal Bank of Scotland plc does not accept responsibility for  
changes made to this message after it was sent.  
   
 
Whilst all reasonable care has been taken to avoid the   
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its   
systems or data.  No responsibility is accepted by The Royal   
Bank of Scotland plc in this regard and the recipient should carry   
out such virus and other checks as it considers appropriate.   
   
Visit our websites at: 
 
http://www.rbs.co.uk/CBFM
http://www.rbsmarkets.com 
   




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)



David Graham wrote:
--- Vic Cekvenich <[EMAIL PROTECTED]> wrote:

And even a simple DAO interface, to be used optionaly be people, so 
they can go back and forth from iBatis to Hibreante or what ever.


I started the Mapper project in the commons for this exact reason.  It
doesn't belong in Struts.
http://jakarta.apache.org/commons/sandbox/mapper/

David


I like the goal.

Thanks for the link, I looked at it but my idea was more of a utra 
simple CRUD DAO interface, taking Collections or XML as arguments. .. 
following the Sun DAO patern (what most people do) but simpler.

ex:
public interface OptionalDAO {
Document retrieveAsXML(Map arg); // so people can implement a DAO that 
executes a retrieve any way they please.
List retrieveAsList(Map arg);
boolean saveXML(Document arg); // so people can implement a DAO that 
saves any way they please.
boolean saveList(List arg);
void beginTran() ;
void endTran();

along those lines.
.V


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Discussion Forum

[EMAIL PROTECTED] wrote:
I favor a evolutionary approach to getting to the
Next Generation of Struts. As apposed to scrapping
every piece of code we have. This would entail aggressively
deprecating functionality.
I believe the plan was to do both. Work can continue on Struts 1.x.x to 
evolve it into an even more useful framework. Meanwhile, work on a new 
codebase for Struts 2.x.x can also proceed.

Of course, when people say "new codebase", I don't think we mean a 
cleanroom implementation. There would be lots of reuse of code that 
already works well.

The relationship between the branches is liable to be synergistic. In 
evolutionary mode, it's sometimes hard to see the forest for the trees, 
and in revolutionary mode is sometimes hard to see the trees for the 
forest :)

In the end, whether Struts 1.x.x evolves into Struts 2.x.x, or whether 
Struts 2.x.x emerges from a revolution, will be up to Darwin. The 
volunteers will elect to spend their time on this or that, and whichever 
approach proves more attractive will win.

In the meantime, it's important to avoid saying whether a given codebase 
will be 2.x.x or not. When the time comes, the community can decide, but 
we'd need a working 2.x.x candidate in front of us first. :)

http://incubator.apache.org/learn/rules-for-revolutionaries.html

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread David Graham


--- Vic Cekvenich <[EMAIL PROTECTED]> wrote:
> 
> And even a simple DAO interface, to be used optionaly be people, so 
> they can go back and forth from iBatis to Hibreante or what ever.

I started the Mapper project in the commons for this exact reason.  It
doesn't belong in Struts.

http://jakarta.apache.org/commons/sandbox/mapper/

David

> 
> And build Struts on top of HiveMind or similar. (IoC and Services... and
> 
> XML).
> 
> If just the MVC interfaces are defined, then several implemenations can 
> ship. One implemtation would be backwards compatible.
> Once could be SOAPActionImpl.
> 
> Action's execute should take a Map as signature argument. This way we do
> 
> not have Req/Resp tie in, but anything comes in.
> Ex: execute(Map arg)  { .. }
> A good 1st step is to have a TilesAction and Action have same signature 
> for execute.
> 
> 
> .V
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread [EMAIL PROTECTED]

I favor a evolutionary approach to getting to the
Next Generation of Struts. As apposed to scrapping
every piece of code we have. This would entail aggressively
deprecating functionality.

The advantages are we would most likely always have
a working framework, which would encourage user
participation, usage, testing. That means we could use it
in our paying jobs. Some of us may even be able to
justify working on Struts 2.0 on our paying Jobs time.
I am concerned where all the energy, time, code, 
documentation, and testing will come from with a clean start.
I strongly believe one of the reasons Struts is so popular
is that we were big on compatibility between releases,
and so staying up to date with the latest Struts release or
nightly was not very painful. 

The disadvantages are that it might seem like we
would have to do extra work in gradually refactoring
Struts into the next version.

Any code base that starts from scratch has to undergo
the painful process of setting up the initial classes,
tests etc... Again user participation, in usage, testing,
and contributions played a major, no, critical role in 
struts's development, and we'll need that same input again.
However, now days there are many other frameworks with which to
choose.

Bottom line is I believe like you do that we are smarter now and
know better ways to do things. Look up Erick Hatchers comments
he made a few months ago on Struts, and ways to improve it as
an example.

-Rob

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 17, 2003 09:22 PM
> To: 'Struts Developers List'
> Subject: Re: Struts 2.0 Discussion Forum
> 
> Don Brown wrote:
>  > Is there one?  I have several ideas I'd like to toss into the
>  > discussion.
>  >
>  > Don
> 
> There's a Whiteboard page in the Wiki.
> 
> http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
> 
> I'll be posting more about Jericho, but wanted to get what I had so far 
> (a starter DTD) under CVS.
> 
> One other idea that I've been meaning to bring up in the wake of 
> wildcard Mappings, is the idea of merging context attributes into 
> ActionForward paths. For example, we could do something like
> 
> 
> 
> and have it replace {key} with request.getAttribute("key") (or session 
> if not found).
> 
> -Ted.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread [EMAIL PROTECTED]

> > >- Also, again totally agreeing with Ted, make everything interface 
> > >based,
> 
> > a few more hears here ;^)
> 
> > Joe Germuska
> 
> The interface discussion has come up previously and there was some emotion
> tied to it.

I was around for Interface ActionForms in pre Struts 0.5 and it was really ugly, what 
some developers tried to do. This then triggered a number of
email's on the list to help them get it working. In almost all cases
they were trying to break the MVC Model, and pile all the logic into the
ActionForm implementation class they possibly could. 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Vic Cekvenich

Martin Cooper wrote:

* Make the Struts core independent of the Servlets spec  
Above is my favorite wish!

I would like to be able to call an Action via XML-RPC for it to give me 
a FormBean and for me to give it a FormBean back. (or any other 
SOA). There was a few threads of SOAP Struts some time back.

And... maybe a FormBean is an XML DTD.
(Like .NET stuff, and iBatis 2.0 _sqlMap.getXMLResult())
This way a view can render it (such as core tags X: ) any way it wants. 
Ex: from javascript you call XML-RPC to get a XML (multirow bean)

And even a simple DAO interface, to be used optionaly be people, so 
they can go back and forth from iBatis to Hibreante or what ever.

And build Struts on top of HiveMind or similar. (IoC and Services... and 
XML).

If just the MVC interfaces are defined, then several implemenations can 
ship. One implemtation would be backwards compatible.
Once could be SOAPActionImpl.

Action's execute should take a Map as signature argument. This way we do 
not have Req/Resp tie in, but anything comes in.
Ex: execute(Map arg)  { .. }
A good 1st step is to have a TilesAction and Action have same signature 
for execute.

.V



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Context attributes (was: Struts 2.0 Discussion Forum)

2003-12-17 Thread gvanmatre

arg = null;
}
}

if (redirect) {
if (!targetArgs.isEmpty()) {
StringBuffer buff = new
StringBuffer(path);

//look for an existing query
string delimiter
boolean firstArg = true;
if (buff.toString().indexOf('?')
> -1) {
firstArg = false;
} else
buff.append("?");

Iterator vi =
targetArgs.keySet().iterator();
while (vi.hasNext()) {
String name = (String)
vi.next();
Object arg =
targetArgs.get(name);
if (arg != null) {
String value =
URLEncoder.encode(arg.toString());


buff.append((firstArg) ? "" : "&").append(

name).append(

"=").append(
value);
firstArg =
false;
value = null;
}
arg = null;
name = null;
}

//build an new ActionForward
with the new query
targetForward = new
ActionForward(buff.toString(), true);

buff = null;
vi = null;
} else
targetForward = this;

} else {
//stage the data pickle in request scope
for the next page
request.setAttribute(

com.rustts.Globals.RUSTTS_FORWARD_KEY,
targetArgs);
targetForward = this;

}

targetNames = null;
sourceArgs = null;
targetArgs = null;
} catch (Exception e) {
targetForward = this;
}

return targetForward;
}

}

-Original Message-
From: Hubert Rabago [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 2:33 PM
To: Struts Developers List
Subject: Re: Context attributes (was: Struts 2.0 Discussion Forum)

What about allowing Action objects to add the parameters themselves?  It
adds a
great deal of flexibility, and doesn't limit the set of parameters that
can be
used, nor does it require using the request or session attributes.

ActionForward forward = mapping.findForward("lookup");
forward.addParameter("param1","value1");
forward.addParameter("param2",2);
forward.addParameter("param3",3.0);
return forward;

Or maybe support for both (merge and addParameter).
This will also make bug 866 go away.

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> Don Brown wrote:
>  > Is there one?  I have several ideas I'd like to toss into the
> discussion.
>  >
>  > Don
>
> There's a Whiteboard page in the Wiki.
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
>
> I'll be posting more about Jericho, but wanted to get what I had so
far
> (a starter DTD) under CVS.
>
> One other idea that I've been meaning to bring up in the wake of
> wildcard Mappings, is the idea of merging context attributes into
> ActionForward paths. For example, we could do something like
>
> 
>
> and have it replace {key} with request.getAttribute("key") (or session

> if not found).
>
> -Ted.
>


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

- To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Martin Cooper wrote:
* Split out file upload handling into a separate pluggable component, with
its own configuration. I noticed that this is still in the initial Jericho
DTD, but I think it should not be. The file upload implementation is
pluggable, and so should be able to have its own config definition.
Feel free to amend that if you like. I've so far managed to avoid file 
uploading in Struts applications, and so remain blissfully ignorant of 
the grittier details.

A sort of meta-question: When is Struts no longer Struts? I mean, how much
change can we introduce in Struts 2.0 before it becomes so different that
it's really a different framework? Do we need to decide on what Struts is,
and is not, before we go too far down the path of Struts 2.0? Or do we let
whatever falls out just fall out and deal with it later?
Legally, I'd say that Strut is whatever the Struts Community says it is. 
It's a brand that belongs to the ASF, which we manage on the 
Foundation's behalf.

Technically, I'd say that Struts (or any framework) is an aggregation of 
its components. In Struts 1.0, we had mainly Form, Forward, Mapping, 
Action, and Messaging components. In Struts 1.1, we added Exception, 
Validation, Composite (or Tile), and PlugIn components.

So long as Struts 2.x retains the same hallmark components in a 
recognizable form, I'd say it's still Struts. :)

Overall, it's my feeling that Struts does all the right things, it's 
just that we don't do them in all the right places. :) Being able to 
extend elements is one example. Encapsulating paths is another.

My own goal for Struts 2.x is to consistently apply all our best 
practices and eliminate inconsistent and legacy practices. We've got a 
good thing here; we just need to make it even better. :)

In terms of new functionality, the three biggest fish I'd like to fry 
are Workflow, SSL, and Unit Testing. Towards that end, I'd like to 
consider integrating LivingLogic's Workflow, ssl-ext, and Struts 
TestCase into the Struts 2.x development stream. We may also want to 
consider adding these as standard options to Struts 1.x, so as to blaze 
a trail.

Although it's not evident from the Jericho DTD, the intention is to use 
a Context object in the signatures, perhaps the Commons Chain Context, 
so as to encapsulate Servlet/Portlet dependencies.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

I think this might be a "that was then, this is now" issue. Once upon a 
time, people were trying to do nutty things like use Entity Beans for 
ActionForms. But people are older and wiser now, and more importantly, 
we have DynaActionForms and tools like XDoclet to mitigate the 
maintenance issues.

In fact, I'd like to merge the ValidatorForm with the DynaActionForm 
configuration, so we'd have a central place to define everything the 
framework wants to know about a form.

On the topic of form processing, I'd also like to add a populate method 
that the Request Processor could call, instead of doing it externally, 
so a form could populate itself.

-Ted.

Don Brown wrote:
Hmm...I'm not familiar with that discussion, but I don't see why general
form functionality couldn't be defined in an interface, but the ActionForm
left how it is.  Of course we also have a chance to do what Craig said
he'd change about Struts (at JavaOne 2003 JSF BOF) and combine forms and
actions.  WebWork2/XWork seems to have done well with that approach.
Again, just throwing ideas out there :)

Don

On Wed, 17 Dec 2003, Edgar P Dollin wrote:


And you're really going to have to break both of my arms and/or kick me
out of Struts development if you want ActionForm *ever* changed to an
interface again -- in *any* future Struts release.  I think it's an
absolutely horrible idea, for reasons that have been documented way too
many times to count.

Craig McClanahan



- Also, again totally agreeing with Ted, make everything interface
based,

a few more hears here ;^)

Joe Germuska
The interface discussion has come up previously and there was some emotion
tied to it.
Edgar

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Hmm...I'm not familiar with that discussion, but I don't see why general
form functionality couldn't be defined in an interface, but the ActionForm
left how it is.  Of course we also have a chance to do what Craig said
he'd change about Struts (at JavaOne 2003 JSF BOF) and combine forms and
actions.  WebWork2/XWork seems to have done well with that approach.

Again, just throwing ideas out there :)

Don

On Wed, 17 Dec 2003, Edgar P Dollin wrote:

> > And you're really going to have to break both of my arms and/or kick me
> > out of Struts development if you want ActionForm *ever* changed to an
> > interface again -- in *any* future Struts release.  I think it's an
> > absolutely horrible idea, for reasons that have been documented way too
> > many times to count.
>
> > Craig McClanahan
>
>
>
> > >- Also, again totally agreeing with Ted, make everything interface
> > >based,
>
> > a few more hears here ;^)
>
> > Joe Germuska
>
> The interface discussion has come up previously and there was some emotion
> tied to it.
>
> Edgar
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Sgarlata Matt

Sorry about that!

You are right, the license is ASF.  It says so both on the SourceForge site
and in the license included in Milestone 3.  I don't know where I got the
idea that it was LGPL.

Matt
- Original Message - 
From: "Don Brown" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, December 17, 2003 5:20 PM
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)


> Nope, Spring is Apache-style, I just checked.  You had me worried there
> for a minute :)
>
> Don
>
> On Wed, 17 Dec 2003, Sgarlata Matt wrote:
>
> > - Original Message -
> > From: "Joe Germuska" <[EMAIL PROTECTED]>
> > To: "Struts Developers List" <[EMAIL PROTECTED]>
> > Sent: Wednesday, December 17, 2003 5:04 PM
> > Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
> >
> >
> > > So then, with specific frameworks,  I don't understand how Pico's
> > > orientation towards constructors works in an environment where beans
> > > need to be dynamically instantiated, but perhaps I just haven't
> > > thought about it hard enough.  Avalon seems too heavy, which leaves
> > > us (or me at least) with Spring and HiveMind.  I haven't developed
> > > with either but so far the docs for Spring give me a warm fuzzy
> > > feeling while the HiveMind docs kind of scare me.
> >
> > I agree with your assessment of frameworks 100%.  However, Spring is
under
> > an LGPL license, so Struts can't use Spring unless either Struts
switches to
> > LGPL or Spring switches to ASF, right?  It would be kind of silly for
Struts
> > to stay under ASF in this case, since the Spring license would force the
> > undesirable LGPL clauses on any projects that were based on Struts.  Am
I
> > right?
> >
> > Matt
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Nope, Spring is Apache-style, I just checked.  You had me worried there
for a minute :)

Don

On Wed, 17 Dec 2003, Sgarlata Matt wrote:

> - Original Message -
> From: "Joe Germuska" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Wednesday, December 17, 2003 5:04 PM
> Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
>
>
> > So then, with specific frameworks,  I don't understand how Pico's
> > orientation towards constructors works in an environment where beans
> > need to be dynamically instantiated, but perhaps I just haven't
> > thought about it hard enough.  Avalon seems too heavy, which leaves
> > us (or me at least) with Spring and HiveMind.  I haven't developed
> > with either but so far the docs for Spring give me a warm fuzzy
> > feeling while the HiveMind docs kind of scare me.
>
> I agree with your assessment of frameworks 100%.  However, Spring is under
> an LGPL license, so Struts can't use Spring unless either Struts switches to
> LGPL or Spring switches to ASF, right?  It would be kind of silly for Struts
> to stay under ASF in this case, since the Spring license would force the
> undesirable LGPL clauses on any projects that were based on Struts.  Am I
> right?
>
> Matt
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Martin Cooper

Just to add a few more off the top of my head:

* Make the Struts core independent of the Servlets spec and the Portlets
spec, so that it can be used for both, and more.

* Separate view-technology-specific code into separate components, so that
the core is view-technology agnostic. So, for example, all JSP specific
code, including all of the taglibs, would move to a JSP component.

* Rework Tiles into two facets, so that the core is independent of the
Servlets spec and JSP, and the JSP component is part of the view specific
component described above.

* Split out file upload handling into a separate pluggable component, with
its own configuration. I noticed that this is still in the initial Jericho
DTD, but I think it should not be. The file upload implementation is
pluggable, and so should be able to have its own config definition.

I know I have more in notes at home, but just wanted to throw these out.

A sort of meta-question: When is Struts no longer Struts? I mean, how much
change can we introduce in Struts 2.0 before it becomes so different that
it's really a different framework? Do we need to decide on what Struts is,
and is not, before we go too far down the path of Struts 2.0? Or do we let
whatever falls out just fall out and deal with it later?

--
Martin Cooper

On Wed, 17 Dec 2003, Don Brown wrote:

> Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> release work. :)  I'll throw out some ideas here, then develop them later
> in the wiki:
>
> - Make Inversion of Control central.  By using an IoC framework to wire
> Struts together, it makes it really easy to extend or improve Struts not
> only for future development but for users as well.  I'd recommend Spring's
> IoC impl as it is small (>100k), really easy to use, and easily
> extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
> frameworks that let you plug in Pico/Spring/Avalon, etc.
>
> - Use XML Schema over DTD's.  Give struts config its own default namespace
> to make it easier for users to mix in elements of other namespaces.  An
> example would be adding custom documentation attributes and elements.  Of
> course the usual arguments for XML Schema over DTD's apply as well.
>
> - Replace paths with URL's, allowing for a default protocol.  An action
> path would look like "action://foo" or a tiles forward would be
> "tiles://tilesdef"  This would make it easy to plug in handlers to support
> different presentation engines.  If no protocol is specified, the path is
> handled as usual.
>
> - As Ted said, contine with the wildcard theme.  Struts should do
> everything possible to cut down configuration.
>
> - Also, again totally agreeing with Ted, make everything interface based,
> have default implementations, and free apps of HTTP.  Ideally, I'd like to
> see extra effort going into making it easy if not effortless to take a
> Struts 2.0 app and use the code in a portlet or web service environment.
> At least in my area, clients are wanting human and machine interfaces,
> with the human interface generally being behind a portal.
>
> Anyways, those are my "brainstorming" thoughts.  If any look interesting,
> I'll write something up in the wiki.
>
> Don
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

On Wed, 17 Dec 2003, Joe Germuska wrote:

> >- Make Inversion of Control central.  By using an IoC framework to wire
> >Struts together, it makes it really easy to extend or improve Struts not
> >only for future development but for users as well.  I'd recommend Spring's
> >IoC impl as it is small (>100k), really easy to use, and easily
> >extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
> >frameworks that let you plug in Pico/Spring/Avalon, etc.
>
> Personally I suspect that a meta framework is more trouble than it's
> worth, although I haven't really looked at any too closely.  (Have
> any pointers)
>
> So then, with specific frameworks,  I don't understand how Pico's
> orientation towards constructors works in an environment where beans
> need to be dynamically instantiated, but perhaps I just haven't
> thought about it hard enough.  Avalon seems too heavy, which leaves
> us (or me at least) with Spring and HiveMind.  I haven't developed
> with either but so far the docs for Spring give me a warm fuzzy
> feeling while the HiveMind docs kind of scare me.

HiveMind, from what I've read, is more service-oriented.  I've been using
Spring for a few months now and totally loving it.  It completely stays
out of your way, leaving your code with little or no Spring dependencies.
Furthermore, it supports both javabean and constructor-style dependency
resolution.

> >- Use XML Schema over DTD's.  Give struts config its own default namespace
> >to make it easier for users to mix in elements of other namespaces.  An
> >example would be adding custom documentation attributes and elements.  Of
> >course the usual arguments for XML Schema over DTD's apply as well.
>
> XML Schema?!  Naw, RelaxNG!!!  After all, it is "now an international
> standard"
> (http://blogs.codehaus.org/people/bob/archives/000505_standards_are_great_everyone_should_have_one.html)

Doesn't matter to me as long as I get namespace support :)

> >- Replace paths with URL's, allowing for a default protocol.  An action
> >path would look like "action://foo" or a tiles forward would be
> >"tiles://tilesdef"  This would make it easy to plug in handlers to support
> >different presentation engines.  If no protocol is specified, the path is
> >handled as usual.
>
> I'm a little sketched out about assigning schemes of our own.  I see
> the motivation, and think the goal is good.  Wonder if we could find
> another mechanism.

Well, I've seen it used particularly in Forrest to good effect.  The key
is keeping the number of "protocols" to a small number, but allowing the
user to develop more if they feel the need.

Don

>
> >- As Ted said, contine with the wildcard theme.  Struts should do
> >everything possible to cut down configuration.
>
> hear, hear! (, hear, hear, hear!!)
>
> >- Also, again totally agreeing with Ted, make everything interface based,
>
> a few more hears here ;^)
>
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
>   "We want beef in dessert if we can get it there."
>-- Betty Hogan, Director of New Product Development, National
> Cattlemen's Beef Association
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread BaTien Duong

Are we on something revolutionary here? I am looking forward to this.

BaTien
DBGROUPS
Don Brown wrote:

Is there one? I have several ideas I'd like to toss into the discussion.

Don

On 17 Dec 2003 [EMAIL PROTECTED] wrote:

husted 2003/12/17 12:49:28

Added: contrib/struts-jericho README.txt project.properties
project.xml
Log:
Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
Revision ChangesPath
1.1 jakarta-struts/contrib/struts-jericho/README.txt
Index: README.txt
===
Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal until the Community comes to a consensus.

This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture. Jericho proposes to open-up Struts by

* Declaring interfaces for all core components.

* Providing working base implementations for all core components.

* Encapsulating alll path references within "Location" objects (fka ActionForwards)and referring only to Locations from all other objects.

* Providing additional extension points from core components so that the "Inversion of Control" pattern is fully realized.

* Providing "POJO" signatures that encapsulate HTTP classes so that applications can be freed of HTTP semantics, if so desired.

* Retain optional access to HTTP objects so that applications can be free to do whatever they need to do.

-Backward Compatibility-

Jericho is a revolution and backward compatability with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practible, so that Jericho is available to the widest community possible.

_DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.

A second alternative to explore is to provide an alternate configuration loader that would map the Struts 1.2 elements to Struts Jericho objects at initialization.

_Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to provided. These classes will provide the Struts 1.2.x behavior but also implement the Struts Jericho interfaces, so that the framework can use them interchangeably.

These same techniques may be applied to provide adaptors for other frameworks, so as to make Struts Jericho available to the widest community possible.

###

1.1 jakarta-struts/contrib/struts-jericho/project.properties

Index: project.properties
===
# ---
# P R O J E C T P R O P E R T I E S
# ---
compile.debug = on
compile.optimize = off
compile.deprecation = off
maven.linkcheck.enable=true

# documentation properties
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html

1.1 jakarta-struts/contrib/struts-jericho/project.xml

Index: project.xml
===

../project.xml
Jericho
struts-jericho
0.1-dev
2003
Struts Jericho 2.x Whiteboard

Jericho is a whiteboard proposal describing one possible implementation of
Struts 2.x.
Since Struts 2.x is slated as a "revolution", the Apache practice is to assign
a codename to a proposal
until the Community comes to a consensus.
This proposal is called "Jericho" since it tries to tear-down the walls within
the Struts architecture.

Ted Husted
husted
[EMAIL PROTECTED]

**/*Test.java

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Edgar P Dollin

> And you're really going to have to break both of my arms and/or kick me
> out of Struts development if you want ActionForm *ever* changed to an
> interface again -- in *any* future Struts release.  I think it's an
> absolutely horrible idea, for reasons that have been documented way too
> many times to count.

> Craig McClanahan



> >- Also, again totally agreeing with Ted, make everything interface 
> >based,

> a few more hears here ;^)

> Joe Germuska

The interface discussion has come up previously and there was some emotion
tied to it.

Edgar


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Sgarlata Matt

- Original Message - 
From: "Joe Germuska" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, December 17, 2003 5:04 PM
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

> So then, with specific frameworks,  I don't understand how Pico's
> orientation towards constructors works in an environment where beans
> need to be dynamically instantiated, but perhaps I just haven't
> thought about it hard enough.  Avalon seems too heavy, which leaves
> us (or me at least) with Spring and HiveMind.  I haven't developed
> with either but so far the docs for Spring give me a warm fuzzy
> feeling while the HiveMind docs kind of scare me.

I agree with your assessment of frameworks 100%.  However, Spring is under
an LGPL license, so Struts can't use Spring unless either Struts switches to
LGPL or Spring switches to ASF, right?  It would be kind of silly for Struts
to stay under ASF in this case, since the Spring license would force the
undesirable LGPL clauses on any projects that were based on Struts.  Am I
right?

Matt

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Joe Germuska

- Make Inversion of Control central. By using an IoC framework to wire
Struts together, it makes it really easy to extend or improve Struts not
only for future development but for users as well. I'd recommend Spring's
IoC impl as it is small (>100k), really easy to use, and easily
extendable. If we wanted to remain more "agnostic", there are "meta" IoC
frameworks that let you plug in Pico/Spring/Avalon, etc.
Personally I suspect that a meta framework is more trouble than it's
worth, although I haven't really looked at any too closely. (Have
any pointers)

So then, with specific frameworks, I don't understand how Pico's
orientation towards constructors works in an environment where beans
need to be dynamically instantiated, but perhaps I just haven't
thought about it hard enough. Avalon seems too heavy, which leaves
us (or me at least) with Spring and HiveMind. I haven't developed
with either but so far the docs for Spring give me a warm fuzzy
feeling while the HiveMind docs kind of scare me.

- Use XML Schema over DTD's. Give struts config its own default namespace
to make it easier for users to mix in elements of other namespaces. An
example would be adding custom documentation attributes and elements. Of
course the usual arguments for XML Schema over DTD's apply as well.
XML Schema?! Naw, RelaxNG!!! After all, it is "now an international
standard"
(http://blogs.codehaus.org/people/bob/archives/000505_standards_are_great_everyone_should_have_one.html)

- Replace paths with URL's, allowing for a default protocol. An action
path would look like "action://foo" or a tiles forward would be
"tiles://tilesdef" This would make it easy to plug in handlers to support
different presentation engines. If no protocol is specified, the path is
handled as usual.
I'm a little sketched out about assigning schemes of our own. I see
the motivation, and think the goal is good. Wonder if we could find
another mechanism.

- As Ted said, contine with the wildcard theme. Struts should do
everything possible to cut down configuration.
hear, hear! (, hear, hear, hear!!)

- Also, again totally agreeing with Ted, make everything interface based,
a few more hears here ;^)

--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
release work. :)  I'll throw out some ideas here, then develop them later
in the wiki:

- Make Inversion of Control central.  By using an IoC framework to wire
Struts together, it makes it really easy to extend or improve Struts not
only for future development but for users as well.  I'd recommend Spring's
IoC impl as it is small (>100k), really easy to use, and easily
extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
frameworks that let you plug in Pico/Spring/Avalon, etc.

- Use XML Schema over DTD's.  Give struts config its own default namespace
to make it easier for users to mix in elements of other namespaces.  An
example would be adding custom documentation attributes and elements.  Of
course the usual arguments for XML Schema over DTD's apply as well.

- Replace paths with URL's, allowing for a default protocol.  An action
path would look like "action://foo" or a tiles forward would be
"tiles://tilesdef"  This would make it easy to plug in handlers to support
different presentation engines.  If no protocol is specified, the path is
handled as usual.

- As Ted said, contine with the wildcard theme.  Struts should do
everything possible to cut down configuration.

- Also, again totally agreeing with Ted, make everything interface based,
have default implementations, and free apps of HTTP.  Ideally, I'd like to
see extra effort going into making it easy if not effortless to take a
Struts 2.0 app and use the code in a portlet or web service environment.
At least in my area, clients are wanting human and machine interfaces,
with the human interface generally being behind a portal.

Anyways, those are my "brainstorming" thoughts.  If any look interesting,
I'll write something up in the wiki.

Don


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread Martin Cooper

On Wed, 17 Dec 2003, Don Brown wrote:

> Is there one?  I have several ideas I'd like to toss into the discussion.

Yep. This is it.

--
Martin Cooper


>
> Don
>
> On 17 Dec 2003 [EMAIL PROTECTED] wrote:
>
> > husted  2003/12/17 12:49:28
> >
> >   Added:   contrib/struts-jericho README.txt project.properties
> > project.xml
> >   Log:
> >   Create whiteboard directory for Struts-Jericho, a working proposal for Struts 
> > 2.x.
> >
> >   Revision  ChangesPath
> >   1.1  jakarta-struts/contrib/struts-jericho/README.txt
> >
> >   Index: README.txt
> >   ===
> >   Jericho is a whiteboard proposal describing one possible implementation of 
> > Struts 2.x.
> >
> >   Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a 
> > codename to a proposal until the Community comes to a consensus.
> >
> >   This proposal is called "Jericho" since it tries to tear-down the walls within 
> > the Struts architecture. Jericho proposes to open-up Struts by
> >
> >   * Declaring interfaces for all core components.
> >
> >   * Providing working base implementations for all core components.
> >
> >   * Encapsulating alll path references within "Location" objects (fka 
> > ActionForwards)and referring only to Locations from all other objects.
> >
> >   * Providing additional extension points from core components so that the 
> > "Inversion of Control" pattern is fully realized.
> >
> >   * Providing "POJO" signatures that encapsulate HTTP classes so that applications 
> > can be freed of HTTP semantics, if so desired.
> >
> >   * Retain optional access to HTTP objects so that applications can be free to do 
> > whatever they need to do.
> >
> >   -Backward Compatibility-
> >
> >   Jericho is a revolution and backward compatability with prior versions of Struts 
> > is not the prime consideration. However, care is being taken to create a clear 
> > migration path, where practible, so that Jericho is available to the widest 
> > community possible.
> >
> >   _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the 
> > Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow 
> > a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
> >
> >   A second alternative to explore is to provide an alternate configuration loader 
> > that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
> >
> >   _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to 
> > provided. These classes will provide the Struts 1.2.x behavior but also implement 
> > the Struts Jericho interfaces, so that the framework can use them interchangeably.
> >
> >   These same techniques may be applied to provide adaptors for other frameworks, 
> > so as to make Struts Jericho available to the widest community possible.
> >
> >   ###
> >
> >
> >   1.1  jakarta-struts/contrib/struts-jericho/project.properties
> >
> >   Index: project.properties
> >   ===
> >   # ---
> >   # P R O J E C T  P R O P E R T I E S
> >   # ---
> >
> >   compile.debug = on
> >   compile.optimize = off
> >   compile.deprecation = off
> >
> >   maven.linkcheck.enable=true
> >
> >   # documentation properties
> >   maven.xdoc.date=left
> >   maven.xdoc.version=${pom.currentVersion}
> >   maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
> >
> >
> >
> >   1.1  jakarta-struts/contrib/struts-jericho/project.xml
> >
> >   Index: project.xml
> >   ===
> >   
> >
> >   
> > ../project.xml
> > Jericho
> > struts-jericho
> > 0.1-dev
> > 2003
> > Struts Jericho 2.x Whiteboard
> > 
> > Jericho is a whiteboard proposal describing one possible implementation of 
> > Struts 2.x.
> > Since Struts 2.x is slated as a "revolution", the Apache practice is to 
> > assign a codename to a proposal
> > until the Community comes to a consensus.
> > This proposal is called "Jericho" since it tries to tear-down the walls 
> > within the Struts architecture.
> > 
> > 
> >   
> > Ted Husted
> > husted
> > [EMAIL PROTECTED]
> > 
> >   
> > 
> >
> > 
> >   
> > 
> >   **/*Test.java
> > 
> >   
> > 
> >
> >   
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail:

Re: Context attributes (was: Struts 2.0 Discussion Forum)

2003-12-17 Thread Hubert Rabago

What about allowing Action objects to add the parameters themselves?  It adds a
great deal of flexibility, and doesn't limit the set of parameters that can be
used, nor does it require using the request or session attributes.

ActionForward forward = mapping.findForward("lookup");
forward.addParameter("param1","value1");
forward.addParameter("param2",2);
forward.addParameter("param3",3.0);
return forward;

Or maybe support for both (merge and addParameter).
This will also make bug 866 go away.

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> Don Brown wrote:
>  > Is there one?  I have several ideas I'd like to toss into the
>  > discussion.
>  >
>  > Don
> 
> There's a Whiteboard page in the Wiki.
> 
> http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
> 
> I'll be posting more about Jericho, but wanted to get what I had so far 
> (a starter DTD) under CVS.
> 
> One other idea that I've been meaning to bring up in the wake of 
> wildcard Mappings, is the idea of merging context attributes into 
> ActionForward paths. For example, we could do something like
> 
> 
> 
> and have it replace {key} with request.getAttribute("key") (or session 
> if not found).
> 
> -Ted.
> 


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Discussion Forum

Don Brown wrote:
> Is there one?  I have several ideas I'd like to toss into the
> discussion.
>
> Don
There's a Whiteboard page in the Wiki.

http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard

I'll be posting more about Jericho, but wanted to get what I had so far 
(a starter DTD) under CVS.

One other idea that I've been meaning to bring up in the wake of 
wildcard Mappings, is the idea of merging context attributes into 
ActionForward paths. For example, we could do something like

and have it replace {key} with request.getAttribute("key") (or session 
if not found).

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread James Mitchell

On Wed, 17 Dec 2003, Don Brown wrote:

> Is there one?  I have several ideas I'd like to toss into the discussion.

I'm +1 for keeping it here on the dev list. (if that's what you meant)



>
> Don
>
> On 17 Dec 2003 [EMAIL PROTECTED] wrote:
>
> > husted  2003/12/17 12:49:28
> >
> >   Added:   contrib/struts-jericho README.txt project.properties
> > project.xml
> >   Log:
> >   Create whiteboard directory for Struts-Jericho, a working proposal for Struts 
> > 2.x.
> >
> >   Revision  ChangesPath
> >   1.1  jakarta-struts/contrib/struts-jericho/README.txt
> >
> >   Index: README.txt
> >   ===
> >   Jericho is a whiteboard proposal describing one possible implementation of 
> > Struts 2.x.
> >
> >   Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a 
> > codename to a proposal until the Community comes to a consensus.
> >
> >   This proposal is called "Jericho" since it tries to tear-down the walls within 
> > the Struts architecture. Jericho proposes to open-up Struts by
> >
> >   * Declaring interfaces for all core components.
> >
> >   * Providing working base implementations for all core components.
> >
> >   * Encapsulating alll path references within "Location" objects (fka 
> > ActionForwards)and referring only to Locations from all other objects.
> >
> >   * Providing additional extension points from core components so that the 
> > "Inversion of Control" pattern is fully realized.
> >
> >   * Providing "POJO" signatures that encapsulate HTTP classes so that applications 
> > can be freed of HTTP semantics, if so desired.
> >
> >   * Retain optional access to HTTP objects so that applications can be free to do 
> > whatever they need to do.
> >
> >   -Backward Compatibility-
> >
> >   Jericho is a revolution and backward compatability with prior versions of Struts 
> > is not the prime consideration. However, care is being taken to create a clear 
> > migration path, where practible, so that Jericho is available to the widest 
> > community possible.
> >
> >   _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the 
> > Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow 
> > a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
> >
> >   A second alternative to explore is to provide an alternate configuration loader 
> > that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
> >
> >   _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to 
> > provided. These classes will provide the Struts 1.2.x behavior but also implement 
> > the Struts Jericho interfaces, so that the framework can use them interchangeably.
> >
> >   These same techniques may be applied to provide adaptors for other frameworks, 
> > so as to make Struts Jericho available to the widest community possible.
> >
> >   ###
> >
> >
> >   1.1  jakarta-struts/contrib/struts-jericho/project.properties
> >
> >   Index: project.properties
> >   ===
> >   # ---
> >   # P R O J E C T  P R O P E R T I E S
> >   # ---
> >
> >   compile.debug = on
> >   compile.optimize = off
> >   compile.deprecation = off
> >
> >   maven.linkcheck.enable=true
> >
> >   # documentation properties
> >   maven.xdoc.date=left
> >   maven.xdoc.version=${pom.currentVersion}
> >   maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
> >
> >
> >
> >   1.1  jakarta-struts/contrib/struts-jericho/project.xml
> >
> >   Index: project.xml
> >   ===
> >   
> >
> >   
> > ../project.xml
> > Jericho
> > struts-jericho
> > 0.1-dev
> > 2003
> > Struts Jericho 2.x Whiteboard
> > 
> > Jericho is a whiteboard proposal describing one possible implementation of 
> > Struts 2.x.
> > Since Struts 2.x is slated as a "revolution", the Apache practice is to 
> > assign a codename to a proposal
> > until the Community comes to a consensus.
> > This proposal is called "Jericho" since it tries to tear-down the walls 
> > within the Struts architecture.
> > 
> > 
> >   
> > Ted Husted
> > husted
> > [EMAIL PROTECTED]
> > 
> >   
> > 
> >
> > 
> >   
> > 
> >   **/*Test.java
> > 
> >   
> > 
> >
> >   
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --

Struts 2.0 Discussion Forum