Alternative is (not at all sure better) is to have soap (similar to way http does) call action, and not have JSP emit XML. Beans are already string properties, easy to make an collection of xml.
The JSP people could do JSTL X: Transform (and... as some know I look for way to do transform in browser) to same action.

.V



Craig R. McClanahan wrote:
Three quick notes:

* We should specifically ask on the user list about the timing
  of Servlet 2.3 / JSP 1.2 dependence.  I would expect this to
  be a bit controversial on that short a time frame.  On the
  other hand, knowing we could interoperate with (and not just
  integrate with) JSTL (and JSF when done) would be nice.

* If the STXX folks are still interested, I'd like to see
  more formal support for XML processing pipelines be included
  in a 1.2 time frame.  This will help people who want to
  leverage Struts in a "web services hype" world, as well as
  being generally useful.

* I'd defer a decision on whether Struts 2.0 advances to Servlet
  2.4 and JSP 2.0 or not for a while yet -- to me, it really
  depends on the adoption rate for J2EE 1.4 and the availability
  of products that run it.  From the Struts perspective, Servlet 2.3->2.4
  doesn't buy a lot, but the JSP 1.2->2.0 changes are going to be
  very very useful.

Craig


On Thu, 17 Oct 2002, Byrne, Steven wrote:


Date: Thu, 17 Oct 2002 14:17:10 -0400
From: "Byrne, Steven" <[EMAIL PROTECTED]>
Reply-To: Struts Developers List <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: RE: RE: Tiles Refactorings for 1.1 compatability

Here's the draft roadmap  that I wrote up.

Struts 1.1
 * Servlet 2.2 / JSP 1.1 based
 * tiles & validator first class citizens
 * tiles module aware
 * validator module aware
 * Struts-el tag lib at contrib status
 * [need help here] ??? factored out into jakarta commons
 * resources factored out into commons-resources?

Struts 1.2   January 2003 [duration: 2 months? ]
 * Servlet 2.3 / JSP 1.2 based
 * Struts-el tag lib integrated
 * Support for distributed struts components within a single
application
   (either by just having a list of them or by using some assembling
   technology)
 * tiles JSTL aware
 * 1.1 bug fixes
 * [need help here] ??? factored out into jakarta commons

Struts 2.0   Q2 2003 [duration: ??? months ]
 * Servlet 2.4 / JSP 2.0
 * JSF integration



[I'm not sure whether to tie these items in with the above roadmap or
not]

Struts 1.2
 * investigate and prototype alternative module organizations including
     * arbitrary levels of nesting
     * locale based structuring
     * inheritance of elements from base types
	  * struts-config
	  * tiles [already has this, but there may be ways to make it
cleaner]
	  * validators
         * investigate adding identifier namespaces




-----Original Message-----
From: Ted Husted [mailto:husted@;apache.org]
Sent: Thursday, October 17, 2002 5:04 AM
To: Struts Developers List
Subject: Re: RE: Tiles Refactorings for 1.1 compatability


I posted a starter version of the roadmap so we'd have
something to patch :0)

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

-Ted.


10/16/2002 4:42:10 PM, "Byrne, Steven" <[EMAIL PROTECTED]> wrote:


Definitely a big part of what 1.1 is all about is
integrating Tiles and

Validator into the main Struts distribution.  Pulling them back into
pseudo-contrib status would not be a good thing.

Has anyone estimated the level of effort to make each of
them be sub-app

aware?  I imagine it's non-trival, but not overly large.
And, since we

have new, eager, smart committers with plenty of energy and
motivation,

I would think that these changes could be done in a reasonable
timeframe, perhaps with a little guidance from the original
authors of

the respective components.

Steve


-----Original Message-----
From: David Graham [mailto:dgraham1980@;hotmail.com]
Sent: Wednesday, October 16, 2002 1:27 PM
To: [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability


To me, validator and tiles are part of the core.  Without
them, struts loses
much of its utility and importance.

David







From: Joe Germuska <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "Struts Developers List"

<[EMAIL PROTECTED]>,

"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: RE: Tiles Refactorings for 1.1 compatability
Date: Wed, 16 Oct 2002 14:54:18 -0500

At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:

> Now that we have modules in play, would anyone VETO adding

the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that

everyone is

waiting for a final release of? I'd have to seriously

consider it.

Would it seriously mess up the current release cycle to
decouple Tiles and

Validator from the core as an attempt to simplify the 1.1
release?  It

seems like there needs to be a "middle-ground" between the
"contrib" folder

and the core where useful tools can be developed and
released without

interfering with the core.

Joe
--
--
* Joe Germuska    { [EMAIL PROTECTED] }
"It's pitiful, sometimes, if they've got it bad. Their eyes
get glazed,

they go white, their hands tremble.... As I watch them I
often feel that a

dope peddler is a gentleman compared with the man who

sells records."

	--Sam Goody, 1956

--
To unsubscribe, e-mail:
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-dev-help@;jakarta.apache.org>

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
To unsubscribe, e-mail:
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-dev-help@;jakarta.apache.org>


--
To unsubscribe, e-mail:
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>

For additional commands, e-mail:
<mailto:struts-dev-help@;jakarta.apache.org>




--
To unsubscribe, e-mail:
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-dev-help@;jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>





--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

Reply via email to