Re: The future of Struts...

[Ted Husted]

See the Struts Roadmap for plans that have been discussed on the Struts 
DEV list.

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

It's important to note that the tags have always been a extension of the 
core framework. The framework originally shipped with a custom tag 
library, because that's what people needed most. Since then, support for 
many other display technologies have been added, including JSTL and JSF, 
as well as XLST and Velocity. For some time, we have been emphasizing 
that Struts is a Controller framework that supports various presentation 
layers.

I'm sure many Struts developers will start using JSF, once the 
specification is finalized and implementations are available -- just as 
many Struts developers are using JSTL today. (While even others use 
XLST, Velocity, and so forth.) For the most part, Struts and JSF are 
complementary. Struts provides a flexible, pluggable request processor. 
JSF provides a rules-based navigational system. Some teams may be able 
to JSF rules that instead of the Struts Controller, others might use the 
Struts controller with JSF tags, or perhaps one for this workflow and 
another for that workflow. It's not an election of remedies. There are a 
lot of gaps in JSF (as well as in Struts 1.1) that can be filled by 
standard, open-source extensions maintained by projects like this one.

If you plan to use JSP tags, and can use Servlet 2.3/JSP 1.2, the best 
longterm JSP tag strategy right now would be to go with JSTL. The 
conventional tags will be supported so long as someone volunteers to do 
the work, but no one seems to be stepping forward. However, tens of 
thousands of applications have shipped with the original tags, so they 
must be doing something right =:0)

But, the thing with a project like Struts, is that it's not about 
planning. It's about doing. The future of Struts lies in the hands of 
people who contribute to the codebase and "make it so".

-Ted.

Marco Tedone wrote:
Hi, is now the future of Struts the integration with JSF and JSTL? Does it
mean that Struts will be only a background framework leaving the
presentation (HTML, JSP) to JSF and JSTL? Is Sun going to open a new project
to build a background framework (a sort of Sun-Struts)?
In this case I wouldn't say that this would be bad (maybe on the opposite!)
but I would like to know it to take strategic decisions for my projects.
Marco



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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>



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

The future of Struts...

[Marco Tedone]

Hi, is now the future of Struts the integration with JSF and JSTL? Does it
mean that Struts will be only a background framework leaving the
presentation (HTML, JSP) to JSF and JSTL? Is Sun going to open a new project
to build a background framework (a sort of Sun-Struts)?

In this case I wouldn't say that this would be bad (maybe on the opposite!)
but I would like to know it to take strategic decisions for my projects.

Marco




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

Re: future of struts

[Craig R. McClanahan]

On Fri, 22 Nov 2002, BaTien Duong wrote:

> Date: Fri, 22 Nov 2002 09:01:22 -0700
> From: BaTien Duong <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: future of struts
>
> Kevin. Thanks for sharing your thought. I am sure that a lot of developers
> already find Strut-Tiles conbinations great for web apps. Since SOAP will be
> the next big thing, we are also thinking along your line in our conceptual
> design stage. Please let the group know any development for Struts-SOAP-JMS.
>

If you want to get involved in discussions like this, I would encourage
you to subscribe to the STRUTS-DEV mailing list, and have discussions
about it there.  We've already started to accumulate ideas into a roadmap
document (http://jakarta.apache.org/struts/status.html) that will help us
flesh out what happens next.  We'll want to keep this list available for
users of the existing Struts versions.

Craig


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

RE: future of struts

[Craig R. McClanahan]

On Fri, 22 Nov 2002, edgar wrote:

> Date: Fri, 22 Nov 2002 09:09:41 -0500
> From: edgar <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>,
>      [EMAIL PROTECTED]
> Subject: RE: future of struts
>
> It is wonderful to be misunderstood.
>

I don't misunderstand you -- I just think you are wrong :-).

> Because struts does so much of the work a big chunk of what is left is
> the tags.  I would compare it to the fit and finish of a car.  How many
> car purchasing decisions are made because the driving is pleasurable or
> the color is correct.
>
> I can understand the groups wanting to minimize the tags importance
> since you are comparing a non MVC situation to a situation with MVC.
> That is missing the point, since now you have a framework (many thanks
> to those who have spent the time putting it together).
>
> My point is that the tags should not be second class citizens.  Yes you
> want to minimize and focus them so that the effort put into them is
> worthwhile.  But we as a user community shouldn't have to rewrite the
> tags to make them useful to our projects or spend silly time triing to
> work through gaps in the usefullness.
>

I would take a slightly different view of this.

One of the reasons people have told me that they chose Struts is the fact
that it imposes *no* restrictions on how you implement your model tier.
Choose DAOs or direct JDBC or EJBs or JDO or XML or ... anything you want,
and it will work fine.  Struts does not impose any "you have to use OUR
model tier interface in order to use the rest of the framework", like many
other frameworks do.

In the view tier, however, the picture is much more confused.  People look
at the Struts tag libraries and don't clearly understand that you *can*
use these (and, if you do, there is some pretty compelling ease-of-use
features), but you don't have to -- as everyone who uses Velocity or XML
or other non-JSP solutions.  The tags themselves are ***not*** the most
valuable thing about the framework -- they are just a convenience for
implementing one of the view tier approaches.

In today's world, the JSTL equivalents for the Struts tags in the bean and
logic libraries are ***much*** more powerful than their Struts
counterparts.  Given that, it makes natural sense for Struts
users to start migrating towards JSTL.  The same thing is going to happen
at the UI component level with JavaServer Faces, when it is finally
released.  Why should users continue to wish for proprietary (to Struts)
tags that are less functional, and work only with JSP (JavaServer Faces is
not limited to use in JSP pages)?

>From my Struts developer perspective, I have a limited number of hours to
devote to Struts.  I would prefer that my hours (and those of other
committers, but that is really their business to decide) be spent
enhancing the unique values that Struts brings (the controller
architecture), and not trying to compete with current and emerging Java
standard APIs that are much better than what we already have.

It's open source -- committers can work on the parts they want.  Users can
submit patches on the things they care about.  But I can guarantee you
that *I* am not going to spend anything more than maintenance time on the
current Struts tag libraries in releases after 1.1.

> Anyway, I will stop swimming upstream.
>
> Edgar

Craig


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

RE: future of struts

[Kevin . Bedell]

> > If Struts is to move to being used as a generic MVC
> > architecture that can be used in a wide range of other
> > environments it may be appropriate to consider  'abstracting'
> > the request and response objects (or at least provide an
> > option to) to isolate them from the HTTP protocol. Otherwise,
> > Struts will likely remain tied to J2EE 'Web Applications'
> > (which I'm not saying is a bad thing). In fact, the value of
> > Struts as a "web application framework" may be great enough
> > that the creation of a generic MVC framework may better be
> > made a Commons project  -  if there is a desire to do this at all.
> >

> I do this currently by a special base Action class that provides a
> handleRequest( UserRequest) which offers all methods for getting
> parameters, attributes, etc. without passing around all those HTTP
> references.. I had talked to Craig about this a while back, and he was
> concerned - for good reason - with backwards compat. If 2.0 is going to
> rip up and rebuild with new servlet technologies and other epiphanies
> over the last 2 years, I would so love to see this abstraction. It would
> make unit testing easier (yes, I've seen the frameworks out and they are
> fine for 1.0/1.1) and just make Struts into a more generic MVC model for
> things like Desktop GUIs and Web Services.

I'd say that this is the best approach - maintain 2 base Action classes.

In fact, it might be worth considering the creation of an 'interface' (or
factory approach, or something) that allows different people to 'plug'
different base Action classes. If it were possible for you to provide your
Action class (for example) in a manner that you met some sort of 'contract'
(be it an interface or whatever), then we'd find all sorts of people
creating base Action classes to tie Struts into all sorts of environments.
Then backward compatibility could be met by simply having one of the Action
class 'options' be backward compatible.

Right now, the ActionServlet extends HttpServlet - this ties struts to J2EE
web applications pretty tightly.

The only way to break this bond would be to have it 'implement' an
interface as its primary responsibility. If you wanted the framework to be
webapp oriented, it could extend HttpServlet as well - but this would have
to be 'not required'.

This is a pretty dramatic change... and unlikely unless someone builds it
and generates support for it. This is 'revolution', not 'evolution'.


> > I've already built a 'command pattern' prototype based on
> > Axis that minimizes the need to define new WSDL for each Web
> > Service 'endpoint' you want to define. We could potentially
> > create a standard WSDL definition that is flexible enough to
> > handle a pretty wide range of applications and then build a
> > backend that maps the web sevice 'command' to a Struts form
> > bean/Action class combination. This would allow you to build
> > web service 'command processors' by implementing Action
> > classes. I've got a lot of the design already in my head.
> >

> That rocks! I have the same time constraints but would love to see this
> come to fruition!

Maybe I'll look into creating a space on sourceforge for this. Let me look
over what I have.

Kevin



---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: future of struts

[BaTien Duong]

Kevin. Thanks for sharing your thought. I am sure that a lot of developers
already find Strut-Tiles conbinations great for web apps. Since SOAP will be
the next big thing, we are also thinking along your line in our conceptual
design stage. Please let the group know any development for Struts-SOAP-JMS.


- Original Message -
From: <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Friday, November 22, 2002 8:24 AM
Subject: RE: future of struts


>
>
>
>
> > In the future, there will be more Struts appplication using even more
> presentation layers,
> >  the Struts tags, the EL  tags, the JSF tags, the Velocity View tools,
> XLST, Jelly,
> > and whatever else we think of next =:0)
> > But behind all this chrome, there can still be the same core framework
> holding all the pieces together.
>
>
>
> I've been putting some thought to this as well. One of the issues that the
> people on the Axis project ran into when they, for example, began looking
> at implementing SOAP over JMS or SMTP instead of HTTP was that they had an
> over-reliance on the HTTP request/response objects. If there was a desire
> to use Struts, for example, as a MVC architecture for use with JMS
> applications, then there would be no HTTP Request or Response objects
> (unless a 'connecter' between JMS and HTTP were created - which would
> defeat the purpose of using JMS anyway).
>
> One of the values in using, for example, JMS is that HTTP is limiting in
> terms of the level of transactional support it can provide. HTTP does not
> guarantee 'once and only once' delivery. If an application required a
> higher level of transactional support than HTTP itself could guarantee,
> then Struts may not be able to be used.
>
> Also, both JMS and SMTP can be Asynchronous - that is, you send a command
> and then the response can come later (or be retrieved by a different
> process). HTTP can't do this.
>
> If Struts is to move to being used as a generic MVC architecture that can
> be used in a wide range of other environments it may be appropriate to
> consider  'abstracting' the request and response objects (or at least
> provide an option to) to isolate them from the HTTP protocol. Otherwise,
> Struts will likely remain tied to J2EE 'Web Applications' (which I'm not
> saying is a bad thing). In fact, the value of Struts as a "web application
> framework" may be great enough that the creation of a generic MVC
framework
> may better be made a Commons project  -  if there is a desire to do this
at
> all.
>
>
>
> All this being said, I've previously offered to collaborate with others on
> the building of a Web Services front end to Struts based on Axis. I've
been
> doing a lot of Web Services work and have used Axis previously. I think
> that being able to use Struts to build Web Services applications that
could
> act as a back-end to .NET or other HTTP-based web services would be great.
> It would make it much easier if you could build the web service 'server'
> components using Action classes, 'form bean's, etc. This isn't something I
> have time for on my own (job. wife, kids, house, etc regularly get in the
> way of all the fun I could have coding this stuff...).
>
> I've already built a 'command pattern' prototype based on Axis that
> minimizes the need to define new WSDL for each Web Service 'endpoint' you
> want to define. We could potentially create a standard WSDL definition
that
> is flexible enough to handle a pretty wide range of applications and then
> build a backend that maps the web sevice 'command' to a Struts form
> bean/Action class combination. This would allow you to build web service
> 'command processors' by implementing Action classes. I've got a lot of the
> design already in my head.
>
>
>
> Kevin
>
>
>
> http://www.strutskickstart.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
-
> This e-mail message (including attachments, if any) is intended for the
use
> of the individual or entity to which it is addressed and may contain
> information that is privileged, proprietary , confidential and exempt from
> disclosure.  If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify the sender and erase this e-mail message immediately.
> --
-
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


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

RE: future of struts

[James Higginbotham]

> If Struts is to move to being used as a generic MVC 
> architecture that can be used in a wide range of other 
> environments it may be appropriate to consider  'abstracting' 
> the request and response objects (or at least provide an 
> option to) to isolate them from the HTTP protocol. Otherwise, 
> Struts will likely remain tied to J2EE 'Web Applications' 
> (which I'm not saying is a bad thing). In fact, the value of 
> Struts as a "web application framework" may be great enough 
> that the creation of a generic MVC framework may better be 
> made a Commons project  -  if there is a desire to do this at all.
>

I do this currently by a special base Action class that provides a
handleRequest( UserRequest) which offers all methods for getting
parameters, attributes, etc. without passing around all those HTTP
references.. I had talked to Craig about this a while back, and he was
concerned - for good reason - with backwards compat. If 2.0 is going to
rip up and rebuild with new servlet technologies and other epiphanies
over the last 2 years, I would so love to see this abstraction. It would
make unit testing easier (yes, I've seen the frameworks out and they are
fine for 1.0/1.1) and just make Struts into a more generic MVC model for
things like Desktop GUIs and Web Services. 
 
> I've already built a 'command pattern' prototype based on 
> Axis that minimizes the need to define new WSDL for each Web 
> Service 'endpoint' you want to define. We could potentially 
> create a standard WSDL definition that is flexible enough to 
> handle a pretty wide range of applications and then build a 
> backend that maps the web sevice 'command' to a Struts form 
> bean/Action class combination. This would allow you to build 
> web service 'command processors' by implementing Action 
> classes. I've got a lot of the design already in my head.
>

That rocks! I have the same time constraints but would love to see this
come to fruition!

James

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: future of struts

[Kevin . Bedell]

> In the future, there will be more Struts appplication using even more
presentation layers,
>  the Struts tags, the EL  tags, the JSF tags, the Velocity View tools,
XLST, Jelly,
> and whatever else we think of next =:0)
> But behind all this chrome, there can still be the same core framework
holding all the pieces together.



I've been putting some thought to this as well. One of the issues that the
people on the Axis project ran into when they, for example, began looking
at implementing SOAP over JMS or SMTP instead of HTTP was that they had an
over-reliance on the HTTP request/response objects. If there was a desire
to use Struts, for example, as a MVC architecture for use with JMS
applications, then there would be no HTTP Request or Response objects
(unless a 'connecter' between JMS and HTTP were created - which would
defeat the purpose of using JMS anyway).

One of the values in using, for example, JMS is that HTTP is limiting in
terms of the level of transactional support it can provide. HTTP does not
guarantee 'once and only once' delivery. If an application required a
higher level of transactional support than HTTP itself could guarantee,
then Struts may not be able to be used.

Also, both JMS and SMTP can be Asynchronous - that is, you send a command
and then the response can come later (or be retrieved by a different
process). HTTP can't do this.

If Struts is to move to being used as a generic MVC architecture that can
be used in a wide range of other environments it may be appropriate to
consider  'abstracting' the request and response objects (or at least
provide an option to) to isolate them from the HTTP protocol. Otherwise,
Struts will likely remain tied to J2EE 'Web Applications' (which I'm not
saying is a bad thing). In fact, the value of Struts as a "web application
framework" may be great enough that the creation of a generic MVC framework
may better be made a Commons project  -  if there is a desire to do this at
all.



All this being said, I've previously offered to collaborate with others on
the building of a Web Services front end to Struts based on Axis. I've been
doing a lot of Web Services work and have used Axis previously. I think
that being able to use Struts to build Web Services applications that could
act as a back-end to .NET or other HTTP-based web services would be great.
It would make it much easier if you could build the web service 'server'
components using Action classes, 'form bean's, etc. This isn't something I
have time for on my own (job. wife, kids, house, etc regularly get in the
way of all the fun I could have coding this stuff...).

I've already built a 'command pattern' prototype based on Axis that
minimizes the need to define new WSDL for each Web Service 'endpoint' you
want to define. We could potentially create a standard WSDL definition that
is flexible enough to handle a pretty wide range of applications and then
build a backend that maps the web sevice 'command' to a Struts form
bean/Action class combination. This would allow you to build web service
'command processors' by implementing Action classes. I've got a lot of the
design already in my head.



Kevin



http://www.strutskickstart.com



































---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: future of struts

[edgar]

It is wonderful to be misunderstood.

Because struts does so much of the work a big chunk of what is left is
the tags.  I would compare it to the fit and finish of a car.  How many
car purchasing decisions are made because the driving is pleasurable or
the color is correct.

I can understand the groups wanting to minimize the tags importance
since you are comparing a non MVC situation to a situation with MVC.
That is missing the point, since now you have a framework (many thanks
to those who have spent the time putting it together). 

My point is that the tags should not be second class citizens.  Yes you
want to minimize and focus them so that the effort put into them is
worthwhile.  But we as a user community shouldn't have to rewrite the
tags to make them useful to our projects or spend silly time triing to
work through gaps in the usefullness.

Anyway, I will stop swimming upstream.

Edgar


-Original Message-
From: Andrew Hill [mailto:[EMAIL PROTECTED]] 
Sent: Friday, November 22, 2002 12:56 AM
To: 'Struts Users Mailing List'
Subject: RE: future of struts


Its sad just how many people seem to have the confusion that struts is
just a bunch of taglibs, and spend forever asking what cool dhtml UI
widgets it provides and wondering what all the fuss is about when they
find it doesnt...

Ive found struts absolutely invaluable in my project, but I personally
consider JSP to be the spawn of satan and dont use so much as a single
JSP for my actual rendering... (Im using a homebaked xhtml DOM rendering
approach)

If I wanted to change the view technology I use, I could in theory just
change the local forwards in my actions (for example to point to JSP
pages) and leave the actions themselves unchanged. (In practice it
wouldn't work too well because I took a few naughty shortcuts when I was
just starting the project but thats my fault and is an 'implementation'
issue rather than a 'design' one!...)

If it wasnt for struts Id have been pretty lost. It would take a month
of Sundays to reimplement all the struts (& commons) features I do use
(ActionServlet, RequestProcessor, Actions, ActionErrors, File Upload &
Multipart form parsing, Digester, Logging, BeanUtils, etc...) and of
course the support struts users get on this mailing list...
:-)

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 08:29
To: [EMAIL PROTECTED]
Subject: RE: future of struts


edgar writes:
>Unfortunately, an innordinately large percentage of development time is

>spent with the tag library, as even a casual perusal of this list 
>reveals.

I think that's mostly about not understanding how to develop with tags,
especially in a Model 2 architecture. It's a very different approach
than developing an app with Model 1 and scriplets. Much of the problem,
I think, is that people try to put old wine into new bottles.

I did some work in Cold Fusion before Struts, so the tag and tool
approaches seemed quite natural to me. I've also written applications in
so many environments now, that I've long started to see the database as
one thing and the presentation as another. So Model 2 came naturally
tool.

IMHO, what helps the most is drawing a firmer contrast between the
Struts Core and the rest of the presentation layer. The Struts tags are
one example of how to expose the Struts framework core to the
presentation page. Struts-el, stxx, the Velocity View tools, and the
(upcoming) struts-faces, are other ways of exposing the core framework
components to the presentation page.

Properly designed, you should be able to use your Struts controller with
any these presentation layers. Where I think people run into problems is
that they try to do controller things in the presentation page and
presentation things in the controller.

Like Vic said, if you are having trouble doing some thing "with" the
tags, it's usually because you are doing too little with the controller.
In a MVC/Model 2 application, the presentation page should be a
glorified mail merge job. It shouldn't "do" anything but output what the
controller has given it to output.

In the future, there will be more Struts appplication using even more
presentation layers, the Struts tags, the EL tags, the JSF tags, the
Velocity View tools, XLST, Jelly, and whatever else we think of next
=:0)

But behind all this chrome, there can still be the same core framework
holding all the pieces together.

-Ted.



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


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


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

RE: future of struts

[Dudley . Butt]

Nicely said!!

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 2:29 AM
To: [EMAIL PROTECTED]
Subject: RE: future of struts


edgar writes:
>Unfortunately, an innordinately large percentage of development 
>time is spent with the tag library, as even a casual perusal
>of this list reveals.

I think that's mostly about not understanding how to develop with 
tags, especially in a Model 2 architecture. It's a very different 
approach than developing an app with Model 1 and scriplets. Much 
of the problem, I think, is that people try to put old wine into 
new bottles. 

I did some work in Cold Fusion before Struts, so the tag and tool 
approaches seemed quite natural to me. I've also written  
applications in so many environments now, that I've long started 
to see the database as one thing and the presentation as another. 
So Model 2 came naturally tool.

IMHO, what helps the most is drawing a firmer contrast between the 
Struts Core and the rest of the presentation layer. The Struts 
tags are one example of how to expose the Struts framework core to 
the presentation page. Struts-el, stxx, the Velocity View tools, 
and the (upcoming) struts-faces, are other ways of exposing the 
core framework components to the presentation page.

Properly designed, you should be able to use your Struts 
controller with any these presentation layers. Where I think 
people run into problems is that they try to do controller things 
in the presentation page and presentation things in the 
controller. 

Like Vic said, if you are having trouble doing some thing "with" 
the tags, it's usually because you are doing too little with the 
controller. In a MVC/Model 2 application, the presentation page 
should be a glorified mail merge job. It shouldn't "do" anything 
but output what the controller has given it to output. 

In the future, there will be more Struts appplication using even 
more presentation layers, the Struts tags, the EL tags, the JSF 
tags, the Velocity View tools, XLST, Jelly, and whatever else we 
think of next =:0) 

But behind all this chrome, there can still be the same core 
framework holding all the pieces together.

-Ted.



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


This message contains information intended solely for the addressee, which is 
confidential or private in nature and subject to legal privilege.
If you are not the intended recipient, you may not peruse, use, disseminate, 
distribute or copy this message or any file attached to this message.
Any such unauthorised use, is prohibited and may be unlawful. If you have received 
this message in error, please notify the sender immediately by e-mail,
facsimile or telephone and thereafter delete the original message from your machine. 
 
Furthermore, the information contained in this message, and any attachments thereto, 
is for information purposes only and may contain the personal views and opinions of 
the author,
which are not necessarily the views and opinions of Dimension Data (South Africa) 
(Proprietary) Limited or its subsidiaries and associated companies ("Dimension Data").
Dimension Data therefore does not accept liability for any claims, loss or damages of 
whatsoever nature, arising as a result of the reliance on such information by anyone. 
 
Whilst all reasonable steps are taken to ensure the accuracy and integrity of 
information transmitted electronically and to preserve the confidentiality thereof,
Dimension Data accepts no liability or responsibility whatsoever if information or 
data is, for whatsoever reason, incorrect, corrupted or does not reach its intended 
destination.  



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

RE: future of struts

[Andrew Hill]

Its sad just how many people seem to have the confusion that struts is just
a bunch of taglibs, and spend forever asking what cool dhtml UI widgets it
provides and wondering what all the fuss is about when they find it
doesnt...

Ive found struts absolutely invaluable in my project, but I personally
consider JSP to be the spawn of satan and dont use so much as a single JSP
for my actual rendering... (Im using a homebaked xhtml DOM rendering
approach)

If I wanted to change the view technology I use, I could in theory just
change the local forwards in my actions (for example to point to JSP pages)
and leave the actions themselves unchanged. (In practice it wouldn't work
too well because I took a few naughty shortcuts when I was just starting the
project but thats my fault and is an 'implementation' issue rather than a
'design' one!...)

If it wasnt for struts Id have been pretty lost. It would take a month of
Sundays to reimplement all the struts (& commons) features I do use
(ActionServlet, RequestProcessor, Actions, ActionErrors, File Upload &
Multipart form parsing, Digester, Logging, BeanUtils, etc...) and of course
the support struts users get on this mailing list...
:-)

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 08:29
To: [EMAIL PROTECTED]
Subject: RE: future of struts


edgar writes:
>Unfortunately, an innordinately large percentage of development
>time is spent with the tag library, as even a casual perusal
>of this list reveals.

I think that's mostly about not understanding how to develop with
tags, especially in a Model 2 architecture. It's a very different
approach than developing an app with Model 1 and scriplets. Much
of the problem, I think, is that people try to put old wine into
new bottles.

I did some work in Cold Fusion before Struts, so the tag and tool
approaches seemed quite natural to me. I've also written
applications in so many environments now, that I've long started
to see the database as one thing and the presentation as another.
So Model 2 came naturally tool.

IMHO, what helps the most is drawing a firmer contrast between the
Struts Core and the rest of the presentation layer. The Struts
tags are one example of how to expose the Struts framework core to
the presentation page. Struts-el, stxx, the Velocity View tools,
and the (upcoming) struts-faces, are other ways of exposing the
core framework components to the presentation page.

Properly designed, you should be able to use your Struts
controller with any these presentation layers. Where I think
people run into problems is that they try to do controller things
in the presentation page and presentation things in the
controller.

Like Vic said, if you are having trouble doing some thing "with"
the tags, it's usually because you are doing too little with the
controller. In a MVC/Model 2 application, the presentation page
should be a glorified mail merge job. It shouldn't "do" anything
but output what the controller has given it to output.

In the future, there will be more Struts appplication using even
more presentation layers, the Struts tags, the EL tags, the JSF
tags, the Velocity View tools, XLST, Jelly, and whatever else we
think of next =:0)

But behind all this chrome, there can still be the same core
framework holding all the pieces together.

-Ted.



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


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

RE: future of struts

[Ted Husted]

edgar writes:
>Unfortunately, an innordinately large percentage of development 
>time is spent with the tag library, as even a casual perusal
>of this list reveals.

I think that's mostly about not understanding how to develop with 
tags, especially in a Model 2 architecture. It's a very different 
approach than developing an app with Model 1 and scriplets. Much 
of the problem, I think, is that people try to put old wine into 
new bottles. 

I did some work in Cold Fusion before Struts, so the tag and tool 
approaches seemed quite natural to me. I've also written  
applications in so many environments now, that I've long started 
to see the database as one thing and the presentation as another. 
So Model 2 came naturally tool.

IMHO, what helps the most is drawing a firmer contrast between the 
Struts Core and the rest of the presentation layer. The Struts 
tags are one example of how to expose the Struts framework core to 
the presentation page. Struts-el, stxx, the Velocity View tools, 
and the (upcoming) struts-faces, are other ways of exposing the 
core framework components to the presentation page.

Properly designed, you should be able to use your Struts 
controller with any these presentation layers. Where I think 
people run into problems is that they try to do controller things 
in the presentation page and presentation things in the 
controller. 

Like Vic said, if you are having trouble doing some thing "with" 
the tags, it's usually because you are doing too little with the 
controller. In a MVC/Model 2 application, the presentation page 
should be a glorified mail merge job. It shouldn't "do" anything 
but output what the controller has given it to output. 

In the future, there will be more Struts appplication using even 
more presentation layers, the Struts tags, the EL tags, the JSF 
tags, the Velocity View tools, XLST, Jelly, and whatever else we 
think of next =:0) 

But behind all this chrome, there can still be the same core 
framework holding all the pieces together.

-Ted.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: future of struts

[V. Cekvenich]

If anyone spends a large percentage of time in the tags, jsp or view, 
then they are not fully using Model2, MVC layers. Alas, there are a lot 
of people who are need help with Struts on this list. (One example: 
newbies tend not to unit test the bean, so they debug it in the JSP.  A 
player uni tests the bean, so no issues in the view, just plop. )
JSP tags are an aside to Struts.

You can and should use JSTL. HTML tag also.

.V

edgar wrote:
This is obviously a true statement, kind of like motherhood and
applepie.  Unfortunately, an innordinately large percentage of
development time is spent with the tag library, as even a casual perusal
of this list reveals.

Any time spent improving the interface to struts has a disproportionate
effect on the efficiency of the developers using the platform.

Anyway, that is my $.02.  ;->

Edgar

-Original Message-
From: micael [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, November 20, 2002 12:02 PM
To: 'Struts Users Mailing List'
Subject: Re: future of struts


There is no issue.  Whether you use struts or not you can still use the 
taglibs.  The taglibs in struts are, in that sense, independent of 
struts.  Struts is an application framework first and a set of taglibs
as a 
bit of an aside, although there are obvious connections.

Micael

At 12:23 PM 11/20/2002 +0100, you wrote:


the following article i found at TheServerSide.com



The tag libraries bundled with Struts provide access to simple and


indexed properties; the


org.apache.struts.taglib.nested package contains tags that access 
simple

and indexed properties in a


nested combination. For a complete list of all tags available with


Struts, refer to the


http://jakarta.apache.org/struts/userGuide/index.html; more resources





on


Struts are available at


http://jakarta.apache.org/struts/resources/index.html. The future


direction of Struts is to transition


over to JavaServer Pages Standard Tag Library (JSTL) and JavaServer


Faces tags.

But what does the last sentence mean. do i have to throw my HTML-pages
away because the STRUTS tags
are not longer needed. Or is there a misunderstanding?

mit freundlichen Grüßen

Georg XL. Mouratidis
Web Application Developer

Heiler|Software AG
Mittlerer Pfad 9
D-70499 Stuttgart

Tel: 0711-139 84-265
Fax: 0711-866 63 01
Email: [EMAIL PROTECTED]

Connecting Buyer and Supplier
http://www.heiler.com

--
To unsubscribe, e-mail:


<mailto:[EMAIL PROTECTED]>


For additional commands, e-mail: 
<mailto:[EMAIL PROTECTED]>


Micael

---

This electronic mail  transmission and any accompanying documents
contain 
information belonging to the sender which may be confidential and
legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent
as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of
the 
information contained in this transmission is strictly prohibited.  If
you 
have received this transmission in error, please delete the message.
Thank you 



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




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

RE: future of struts

[edgar]

This is obviously a true statement, kind of like motherhood and
applepie.  Unfortunately, an innordinately large percentage of
development time is spent with the tag library, as even a casual perusal
of this list reveals.

Any time spent improving the interface to struts has a disproportionate
effect on the efficiency of the developers using the platform.

Anyway, that is my $.02.  ;->

Edgar

-Original Message-
From: micael [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, November 20, 2002 12:02 PM
To: 'Struts Users Mailing List'
Subject: Re: future of struts


There is no issue.  Whether you use struts or not you can still use the 
taglibs.  The taglibs in struts are, in that sense, independent of 
struts.  Struts is an application framework first and a set of taglibs
as a 
bit of an aside, although there are obvious connections.

Micael

At 12:23 PM 11/20/2002 +0100, you wrote:

>the following article i found at TheServerSide.com
>
> >The tag libraries bundled with Struts provide access to simple and
> indexed properties; the
> >org.apache.struts.taglib.nested package contains tags that access 
> >simple
> and indexed properties in a
> >nested combination. For a complete list of all tags available with
> Struts, refer to the
> >http://jakarta.apache.org/struts/userGuide/index.html; more resources

> >on
> Struts are available at
> >http://jakarta.apache.org/struts/resources/index.html. The future
> direction of Struts is to transition
> >over to JavaServer Pages Standard Tag Library (JSTL) and JavaServer
> Faces tags.
>
>But what does the last sentence mean. do i have to throw my HTML-pages
>away because the STRUTS tags
>are not longer needed. Or is there a misunderstanding?
>
>mit freundlichen Grüßen
>
>Georg XL. Mouratidis
>Web Application Developer
>
>Heiler|Software AG
>Mittlerer Pfad 9
>D-70499 Stuttgart
>
>Tel: 0711-139 84-265
>Fax: 0711-866 63 01
>Email: [EMAIL PROTECTED]
>
>Connecting Buyer and Supplier
>http://www.heiler.com
>
>--
>To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>

Micael

---

This electronic mail  transmission and any accompanying documents
contain 
information belonging to the sender which may be confidential and
legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent
as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of
the 
information contained in this transmission is strictly prohibited.  If
you 
have received this transmission in error, please delete the message.
Thank you 



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


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

Re: future of struts

[micael]

There is no issue.  Whether you use struts or not you can still use the 
taglibs.  The taglibs in struts are, in that sense, independent of 
struts.  Struts is an application framework first and a set of taglibs as a 
bit of an aside, although there are obvious connections.

Micael

At 12:23 PM 11/20/2002 +0100, you wrote:

the following article i found at TheServerSide.com

>The tag libraries bundled with Struts provide access to simple and 
indexed properties; the
>org.apache.struts.taglib.nested package contains tags that access simple 
and indexed properties in a
>nested combination. For a complete list of all tags available with 
Struts, refer to the
>http://jakarta.apache.org/struts/userGuide/index.html; more resources on 
Struts are available at
>http://jakarta.apache.org/struts/resources/index.html. The future 
direction of Struts is to transition
>over to JavaServer Pages Standard Tag Library (JSTL) and JavaServer 
Faces tags.

But what does the last sentence mean. do i have to throw my HTML-pages 
away because the STRUTS tags
are not longer needed. Or is there a misunderstanding?

mit freundlichen Grüßen

Georg XL. Mouratidis
Web Application Developer

Heiler|Software AG
Mittlerer Pfad 9
D-70499 Stuttgart

Tel: 0711-139 84-265
Fax: 0711-866 63 01
Email: [EMAIL PROTECTED]

Connecting Buyer and Supplier
http://www.heiler.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Micael

---

This electronic mail  transmission and any accompanying documents contain 
information belonging to the sender which may be confidential and legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of the 
information contained in this transmission is strictly prohibited.  If you 
have received this transmission in error, please delete the message.  Thank you 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: future of struts

[David Graham]

The Struts html tags will continue to be a part of Struts even after JSF 
becomes more popular.  However, you should use standard technologies 
whenever possible so the Struts team is advocating using JSF instead of the 
html tags in the future.  You will not have to throw any existing code away.

David






From: "Mouratidis, Georg" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: future of struts
Date: Wed, 20 Nov 2002 12:23:24 +0100


the following article i found at TheServerSide.com

>The tag libraries bundled with Struts provide access to simple and 
indexed properties; the
>org.apache.struts.taglib.nested package contains tags that access simple 
and indexed properties in a
>nested combination. For a complete list of all tags available with 
Struts, refer to the
>http://jakarta.apache.org/struts/userGuide/index.html; more resources on 
Struts are available at
>http://jakarta.apache.org/struts/resources/index.html. The future 
direction of Struts is to transition
>over to JavaServer Pages Standard Tag Library (JSTL) and JavaServer Faces 
tags.

But what does the last sentence mean. do i have to throw my HTML-pages away 
because the STRUTS tags
are not longer needed. Or is there a misunderstanding?

mit freundlichen Grüßen

Georg XL. Mouratidis
Web Application Developer

Heiler|Software AG
Mittlerer Pfad 9
D-70499 Stuttgart

Tel: 0711-139 84-265
Fax: 0711-866 63 01
Email: [EMAIL PROTECTED]

Connecting Buyer and Supplier
http://www.heiler.com

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


_
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus


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

future of struts

[Mouratidis, Georg]

the following article i found at TheServerSide.com

>The tag libraries bundled with Struts provide access to simple and indexed 
>properties; the
>org.apache.struts.taglib.nested package contains tags that access simple and indexed 
>properties in a
>nested combination. For a complete list of all tags available with Struts, refer to 
>the
>http://jakarta.apache.org/struts/userGuide/index.html; more resources on Struts are 
>available at
>http://jakarta.apache.org/struts/resources/index.html. The future direction of Struts 
>is to transition
>over to JavaServer Pages Standard Tag Library (JSTL) and JavaServer Faces tags.

But what does the last sentence mean. do i have to throw my HTML-pages away because 
the STRUTS tags
are not longer needed. Or is there a misunderstanding?

mit freundlichen Grüßen 

Georg XL. Mouratidis 
Web Application Developer 

Heiler|Software AG 
Mittlerer Pfad 9 
D-70499 Stuttgart 

Tel: 0711-139 84-265
Fax: 0711-866 63 01 
Email: [EMAIL PROTECTED] 

Connecting Buyer and Supplier
http://www.heiler.com 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: