You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Richard Reyes <ri...@voxsant.com> on 2004/07/15 08:16:29 UTC
Struts Sample / Best Practices for Database access
Hi Guys,
Newbie question, where can i get struts sample application using
database components like DAO, JDO or Hibernate samples.
Thanks
Richard
Re: Struts Sample / Best Practices for Database access
Posted by Vic Cekvenich <ce...@portalvu.com>.
http://www.reumann.net/do/struts/ibatisLesson1
Richard Reyes wrote:
> Hi Guys,
>
> Newbie question, where can i get struts sample application using
> database components like DAO, JDO or Hibernate samples.
>
> Thanks
> Richard
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts Sample / Best Practices for Database access
Posted by Van <va...@gmail.com>.
On Thu, 15 Jul 2004 14:16:29 +0800, Richard Reyes <ri...@voxsant.com> wrote:
> Newbie question, where can i get struts sample application using
> database components like DAO, JDO or Hibernate samples.
I never quite get around to downloading it and taking a look at it
myself, but, I hear good things about AppFuse. It has much more than
just the database component samples you asked about, but, it
definitely would have examples of Struts being used with Hibernate.
It might be worth a look.
https://appfuse.dev.java.net/
--
- Mike "Van" Riper
van.riper@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts Sample / Best Practices for Database access
Posted by Hubert Rabago <ja...@yahoo.com>.
The mailreader app is included with the 1.2.1 distribution.
http://cvs.apache.org/dist/struts/v1.2.1/
--- Richard Reyes <ri...@voxsant.com> wrote:
> Thanks Ted. Where can i get the mailreader webapp again?
>
> Ted Husted wrote:
>
> >This is kind of a trick question, or at least a trick subject.
> >
> >In a Struts application, the best practice for database access is for
> Struts to be unaware that there is even such a thing as a database. If you
> are using the Struts best practice, then it shouldn't matter whether the
> database example is in a Struts application or not.
> >
> >The Struts Mailreader demonstrates an excellent practice for database
> access. It defines an POJO interface with the methods that accept and/or
> return the data that the application needs. The Actions expect that
> singleton instances of these plain-old Java objects will be in application
> scope under a known name. The Actions speak only to the interface. A Struts
> PlugIn loads an implementation of the interfaces into application scope
> under the expected names, and we are ready to rock.
> >
> >The POJO JavaBeans can be implemented using whatever technology you like.
> They should not know there are living in a Struts application, or even a
> Web application, and should be fully testable. You should be able to write
> them using stock examples for your chosen technology, blissfully unaware of
> whether they will be used by Struts or not.
> >
> >-Ted.
> >
> >On Thu, 15 Jul 2004 14:16:29 +0800, Richard Reyes wrote:
> >
> >
> >> Hi Guys,
> >>
> >> Newbie question, where can i get struts sample application using
> >> database components like DAO, JDO or Hibernate samples.
> >>
> >> Thanks
> >> Richard
> >>
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
> >
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts Sample / Best Practices for Database access
Posted by Richard Reyes <ri...@voxsant.com>.
Thanks Ted. Where can i get the mailreader webapp again?
Ted Husted wrote:
>This is kind of a trick question, or at least a trick subject.
>
>In a Struts application, the best practice for database access is for Struts to be unaware that there is even such a thing as a database. If you are using the Struts best practice, then it shouldn't matter whether the database example is in a Struts application or not.
>
>The Struts Mailreader demonstrates an excellent practice for database access. It defines an POJO interface with the methods that accept and/or return the data that the application needs. The Actions expect that singleton instances of these plain-old Java objects will be in application scope under a known name. The Actions speak only to the interface. A Struts PlugIn loads an implementation of the interfaces into application scope under the expected names, and we are ready to rock.
>
>The POJO JavaBeans can be implemented using whatever technology you like. They should not know there are living in a Struts application, or even a Web application, and should be fully testable. You should be able to write them using stock examples for your chosen technology, blissfully unaware of whether they will be used by Struts or not.
>
>-Ted.
>
>On Thu, 15 Jul 2004 14:16:29 +0800, Richard Reyes wrote:
>
>
>> Hi Guys,
>>
>> Newbie question, where can i get struts sample application using
>> database components like DAO, JDO or Hibernate samples.
>>
>> Thanks
>> Richard
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
Re: JSF vs Struts
Posted by Craig McClanahan <cr...@gmail.com>.
>
> What exactly is officially to be considered a 'corporate developer'?
> Honestly, for I don't know. The common VB guy who neither cares
> nor even knows much apart from 'point-and-click and it's done,
> obviously'?
>
A corporate developer is more known by what she or he knows, than by
what tools they use (although VB will certainly be common). In
general, the corporate developers that we (the Creator team) focused
on are those that have one or more of the following characteristics:
* Are primarily engaged in some knowledge worker task,
and are not professional software developers.
* Would typically first go to an internal IT department
for an application to access the company's internal
databases, often to be frustrated by how long the
backlog typically is in such organizations.
* Is willing to learn a little bit about visual development
and/or scripting; is not (usually) willing to understand
more esoteric things lke object oriented programming.
* Likes to build by cut-n-paste-n-edit from starting point
examples, rather than creating designs from scratch.
* Can "consume" things like database schemas and simple
web services that provide lists of data back; typically
less capable of "creating" such architectures.
* Work product is more typically used at the departmental
level than at the enterprise level (so scalability and
performance are not typically the highest ranked priorities).
Before I joined Sun, I worked for a company that provided information
services to the long haul trucking industry. When I left, there were
about 350 employees; 20 software engineers (building the products we
sold and provided services through -- in Java), 10 in IT running the
internal customer and billing systems (mostly a combination of a GUI
scripting language plus third party COTS software), and about 200
knowledge workers in various fields (typically using MS Access and MS
Excel to retrieve data from the corporate database) in various fields.
Many of those knowledge workers found it necessary to build some of
their own data retrieval tools, because there was no way the IT group
could get around to meeting everyone's needs, and became corporate
developers.
I expect that this kind of ratio between folks who know and love Java,
and those who are just trying to get their job done, is not unusual.
I also see it as a *huge* opportunity for Java as a platform, if we
can just make it easier for them to use.
This doesn't require sacrificing all our up-to-the-second passionate
debates about MVC, IoC, SoA, persistence tiers, AOP, design patterns,
or any of that. It does require recognizing that not everyone in the
world knows, or ever wants to know, some of the things we O-O folks
tend to care about.
> -- Chris.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts
Posted by Christian Bollmeyer <ja...@christianbollmeyer.de>.
On Sunday 18 July 2004 19:08, Craig McClanahan wrote:
+1. But one thing I always wondered about, and as you
brought the term into play here:
> I suspect Bryan might be confusing particular tools (i.e. Sun Java
> Studio Creator, deliberately aimed at corporate developers) with the
> underlying technology of JSF (which is already being supported across
> a wide variety of traditional Java-developer-oriented tools).
What exactly is officially to be considered a 'corporate developer'?
Honestly, for I don't know. The common VB guy who neither cares
nor even knows much apart from 'point-and-click and it's done,
obviously'?
-- Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OT: Re: Velocity vs tags (was JSF vs Struts)
Posted by David Evans <ds...@berndtgroup.net>.
On Thu, 2004-07-22 at 21:59, Rick Reumann wrote:
> David Evans wrote:
>
> > Velocitys other big sellling point to me is
> > that i can use it during an action's execution, for instance, to create
> > files on disc. theres no way to do that with jsp is there?
>
> Not sure what you mean by writing files to disc? You mean writing to the
> server's file system? If so, I would never consider doing that from a
> front end view component, but I'm thinking you must mean something else?
> The point of any view layer should be purely presentational. And as
> Craig mentioned JSP 2.0 makes it very clean to grab any object property
> out of any context ie..
>
> Hi my name is ${userObject.jspIsCoolUserName}.
Some parts of our web site are made of static HTML pages, that are
created dynamically when ever certain actions are taken in the backend
application. so the admin user clicks a button and a static html page is
recreated. the reasoning behind this process is that these pages are
more easily discovered by search engines. or thats what i've been told
by the creator of the system. the system was in place when i got here,
and i can't change it.
dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OT: Re: Velocity vs tags (was JSF vs Struts)
Posted by Rick Reumann <st...@reumann.net>.
David Evans wrote:
> Velocitys other big sellling point to me is
> that i can use it during an action's execution, for instance, to create
> files on disc. theres no way to do that with jsp is there?
Not sure what you mean by writing files to disc? You mean writing to the
server's file system? If so, I would never consider doing that from a
front end view component, but I'm thinking you must mean something else?
The point of any view layer should be purely presentational. And as
Craig mentioned JSP 2.0 makes it very clean to grab any object property
out of any context ie..
Hi my name is ${userObject.jspIsCoolUserName}.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OT: Re: Velocity vs tags (was JSF vs Struts)
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 22 Jul 2004 14:38:55 -0400, David Evans <ds...@berndtgroup.net> wrote:
>
> Thanks, i didn't know that. Velocitys other big sellling point to me is
> that i can use it during an action's execution, for instance, to create
> files on disc. theres no way to do that with jsp is there? cause having
> the one template language for all my needs is nice.
Currently JSP is tied to the web tier. Making it less tied (so you
could do things like this) is a topic that periodically comes up ...
if you'd like to encourage that, send feedback to the JSP expert group
encouraging it:
jsp-spec-comments@eng.sun.com
>
> dave
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OT: Re: Velocity vs tags (was JSF vs Struts)
Posted by David Evans <ds...@berndtgroup.net>.
On Thu, 2004-07-22 at 13:43, Craig McClanahan wrote:
> On Thu, 22 Jul 2004 10:33:35 -0400, David Evans <ds...@berndtgroup.net> wrote:
> > Thanks for the input. i can see what you mean about the conditionals and
> > looping looking cleaner. but the ease of use of sticking any kind of
> > java object in the context and calling out its properties by
> > $object.property or $object.nestedObject.property is the part of
> > velocity that i think is cleaner. tastes vary.
> >
>
> Note that JSP 2.0 provides essentially the same thing anywhere in
> template text, not just in tag attributes ... the only difference is
> you need curly braces around the expressions:
>
> <p>Hello ${customer.name},</p>
>
> <p>Your account balance is ${customer.account.total} and
> was due on ${customer.account.dueDate}. Pay up or else!</p>
>
> <p>Your friendly accounts receiveable team</p>
>
> > dave
>
> Craig
Thanks, i didn't know that. Velocitys other big sellling point to me is
that i can use it during an action's execution, for instance, to create
files on disc. theres no way to do that with jsp is there? cause having
the one template language for all my needs is nice.
dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OT: Re: Velocity vs tags (was JSF vs Struts)
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 22 Jul 2004 10:33:35 -0400, David Evans <ds...@berndtgroup.net> wrote:
> Thanks for the input. i can see what you mean about the conditionals and
> looping looking cleaner. but the ease of use of sticking any kind of
> java object in the context and calling out its properties by
> $object.property or $object.nestedObject.property is the part of
> velocity that i think is cleaner. tastes vary.
>
Note that JSP 2.0 provides essentially the same thing anywhere in
template text, not just in tag attributes ... the only difference is
you need curly braces around the expressions:
<p>Hello ${customer.name},</p>
<p>Your account balance is ${customer.account.total} and
was due on ${customer.account.dueDate}. Pay up or else!</p>
<p>Your friendly accounts receiveable team</p>
> dave
Craig
>
> On Wed, 2004-07-21 at 22:37, Rick Reumann wrote:
> > David Evans wrote:
> >
> > > Could you elaborate on what you find distastful about Velocity?
> >
> > I wasn't being "all" seriously when I said "yuk":) but seriously I do
> > find that when you have a decent amount of conditional logic on a page
> > (which sometimes during presentation is unavoidable if you want to
> > re-use a page/template), I think JSTL <c:when><c:otherwise> constructs
> > look cleaner. Mind you, "bad" JSP with a bunch of scriplets is horrible,
> > but JSP 2.0 and JSTL looks pretty sweat. More of a matter of preference
> > though I guess.
> >
> > Actually a bunch of us get in this debate a lot and it would be
> > interesting to see a "code off" challenge of two views (JSP vs Velocity)
> > done to best standards and dealing with a fairly complex presentation.
> > Usually the examples you see either bastardize one or the other and
> > don't treat the opposing view fairly.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
OT: Re: Velocity vs tags (was JSF vs Struts)
Posted by David Evans <ds...@berndtgroup.net>.
Thanks for the input. i can see what you mean about the conditionals and
looping looking cleaner. but the ease of use of sticking any kind of
java object in the context and calling out its properties by
$object.property or $object.nestedObject.property is the part of
velocity that i think is cleaner. tastes vary.
dave
On Wed, 2004-07-21 at 22:37, Rick Reumann wrote:
> David Evans wrote:
>
> > Could you elaborate on what you find distastful about Velocity?
>
> I wasn't being "all" seriously when I said "yuk":) but seriously I do
> find that when you have a decent amount of conditional logic on a page
> (which sometimes during presentation is unavoidable if you want to
> re-use a page/template), I think JSTL <c:when><c:otherwise> constructs
> look cleaner. Mind you, "bad" JSP with a bunch of scriplets is horrible,
> but JSP 2.0 and JSTL looks pretty sweat. More of a matter of preference
> though I guess.
>
> Actually a bunch of us get in this debate a lot and it would be
> interesting to see a "code off" challenge of two views (JSP vs Velocity)
> done to best standards and dealing with a fairly complex presentation.
> Usually the examples you see either bastardize one or the other and
> don't treat the opposing view fairly.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Velocity vs tags (was JSF vs Struts)
Posted by Rick Reumann <st...@reumann.net>.
David Evans wrote:
> Could you elaborate on what you find distastful about Velocity?
I wasn't being "all" seriously when I said "yuk":) but seriously I do
find that when you have a decent amount of conditional logic on a page
(which sometimes during presentation is unavoidable if you want to
re-use a page/template), I think JSTL <c:when><c:otherwise> constructs
look cleaner. Mind you, "bad" JSP with a bunch of scriplets is horrible,
but JSP 2.0 and JSTL looks pretty sweat. More of a matter of preference
though I guess.
Actually a bunch of us get in this debate a lot and it would be
interesting to see a "code off" challenge of two views (JSP vs Velocity)
done to best standards and dealing with a fairly complex presentation.
Usually the examples you see either bastardize one or the other and
don't treat the opposing view fairly.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Velocity vs tags (was JSF vs Struts)
Posted by David Evans <ds...@berndtgroup.net>.
Rick,
Could you elaborate on what you find distastful about Velocity? I've
just started using it as my primary presentation layer tool in struts,
because i found the templating language so clean and clear. The ablitiy
to stick what ever object i'd like in its context, and then refer to it
in a simple intuitive language construct was fresh air for me. Tastes
vary, i know, but maybe you've run across things i haven't yet, that
turned you off.
dave
On Sun, 2004-07-18 at 23:56, Rick Reumann wrote:
> Craig McClanahan wrote:
>
> > For applications you are about to start on, if it is your intent to
> > use the Struts HTML tags for your view tier, you should review that
> > decision in the light of the developments of the last few months,
> > since the JSF spec went final, to say nothing of the availability of
> > alternative view tier technologies (XML, Velocity, ...) that work with
> > Struts as well. If these tags work for you, that's fine ... but be
> > aware that you are buying in to a mature technology that is unlikely
> > to change much in the future.
>
> Craig, can you elaborate on this a bit more? I'm confused because if you
> went with a different front end presentation other than JSP and Struts
> HTML form tags, why would it matter that you chose Struts HTML tags for
> the JSP portion? If you later chose an XML/XSLT or Velocity
> (yuk:)solution for your view you'd end up scrapping the JSPs altogether
> anyway so why would it matter what tags you used to build the JSPs that
> you would be replacing? Or are you basically saying to not even bothr
> using JSPs for a front end view? (I've seen good velocity templates and
> I'll take a *clean* JSP using JSTL and tags over Velocity any day of the
> week). Thanks for your thoughts and all your work on Struts, JSF,
> Tomcat, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
http 405 error
Posted by Sandy Bingham-Porter <cs...@eiu.edu>.
Would anyone have any ideas why I would be receiving a 405 error (page
cannot be displayed address is incorrect) when my struts application
tries to initiate a .do action servlet call?
I have checked the web.xml file and ensured the servlet mapping for all
*.do paths are correct. If I tried to access a page directly (jsp) that
uses the struts-html.tld tag library, I get errors informing me that the
tag definitions cannot be found. I have also verified that the .tld is
present.
Any help would be greatly appreciated,
Sandy Bingham-Porter
Ecommerce Development
Eastern Illinois University
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 19 Jul 2004 10:25:13 -0400, Rick Reumann <st...@reumann.net> wrote:
>
> We're thinking about using Flash forms for some things. Will they plugin
> nicely to JSF?
>
Hooking up the output side of that should be a piece of cake ... write
some components that render the necessary markup to embed the Flash
stuff in the generated page. I'm not familiar with the input side of
using Flash for this, but in principle it should still just be a
matter of having your component (or renderer) decode() method parse
the appropriate request parameters and store the values, just as the
standard HTML components do.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: JSF vs Struts
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
Rick,
cocoon is able to *render* flash as well,
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/serialization/SWF
Serializer.html
perhaps you got some ideas on this clazz
regards,
> -----Original Message-----
> From: Rick Reumann [mailto:struttin@reumann.net]
> Sent: Monday, July 19, 2004 4:25 PM
> To: Struts Users Mailing List
> Subject: Re: JSF vs Struts
>
>
> Craig McClanahan wrote:
>
> > With JSF, however, the situation is different. Every JSF component
> > is, at its core, just a JavaBean ... it doesn't care what
> technology
> > is used to ultimately manage the page. Yes, we provide JSP tag
> > wrappers around all the standard components (because that addresses
> > the need of a very large portion of the marketplace), but it's not
> > required. The reason is that JSF provides a pluggable ViewHandler
> > implementation ... the default one does RequestDispatcher.forward()
> > calls (just like Struts does), making it very easy to use JSP, but
> > this is by no means required.
> >
> > You like Tapestry style separation of the component tree definition
> > from the static HTML text? That's not hard ... go get
> Hans's JSF book
> > and read the last chapter, to get you 80% of the way to a robust
> > ViewHandler solution.
> >
> > Maybe you'd prefer XForms? Go for it ... writing a
> ViewHandler that
> > transforms your favorite way of representing a component
> tree into an
> > XForms document is MMP (Merely a Matter of Programming :-).
> >
> > Or, maybe you'd prefer an XML based solution that has all the
> > component stuff in a single file, and you're contemplating an XSLT
> > based solution that transforms component definitions into the
> > corresponding HTML. Go for it. (Of, course, if you use the XML
> > syntax for JSP pages plus JSF component tags, you get this
> pretty much
> > for free ... oops, sorry, forgot you might be one of those that
> > doesn't like JSP :-).
>
> We're thinking about using Flash forms for some things. Will
> they plugin
> nicely to JSF?
>
> --
> Rick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts
Posted by Rick Reumann <st...@reumann.net>.
Craig McClanahan wrote:
> With JSF, however, the situation is different. Every JSF component
> is, at its core, just a JavaBean ... it doesn't care what technology
> is used to ultimately manage the page. Yes, we provide JSP tag
> wrappers around all the standard components (because that addresses
> the need of a very large portion of the marketplace), but it's not
> required. The reason is that JSF provides a pluggable ViewHandler
> implementation ... the default one does RequestDispatcher.forward()
> calls (just like Struts does), making it very easy to use JSP, but
> this is by no means required.
>
> You like Tapestry style separation of the component tree definition
> from the static HTML text? That's not hard ... go get Hans's JSF book
> and read the last chapter, to get you 80% of the way to a robust
> ViewHandler solution.
>
> Maybe you'd prefer XForms? Go for it ... writing a ViewHandler that
> transforms your favorite way of representing a component tree into an
> XForms document is MMP (Merely a Matter of Programming :-).
>
> Or, maybe you'd prefer an XML based solution that has all the
> component stuff in a single file, and you're contemplating an XSLT
> based solution that transforms component definitions into the
> corresponding HTML. Go for it. (Of, course, if you use the XML
> syntax for JSP pages plus JSF component tags, you get this pretty much
> for free ... oops, sorry, forgot you might be one of those that
> doesn't like JSP :-).
We're thinking about using Flash forms for some things. Will they plugin
nicely to JSF?
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts - Development Process Questions
Posted by Bryan Hunt <ad...@revoltingdigits.com>.
JSF with spring and hibernate tutorial.
http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html
<http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html>
Guess I should read it before I comment again.
--b
Bryan Hunt wrote:
> +1
>
> I am sceptical about this technology but potentially it could be good.
> I'm going to look at JSF in 6 months
> or a years time when it is clearer if this is going to be another
> timewaster/project wrecker or something
> usefull and useable.
>
> In the meantime I recomend NitroX as well although I don't like the
> companys "patent pending" bs about
> their "app x ray" technology....
>
> Things like that don't make me particularly enthusiastic as someone
> who has to constantly worry about
> software patents when I'm writing a LGPL app/using a linux server.
>
> --b
>
> Mike Duffy wrote:
>
>> I have some questions regarding the development process when using
>> JSF, especially in realtion to
>> HTML designers. Will everyone on the team need the same advanced
>> design tools? Will the
>> designers who are used to tweaking HTML/JSP be restricted to a
>> completely visual drag and drop
>> environment? Or even worse, will the HTML designers be required to
>> learn JSF mark up code?
>> There was another thread a few weeks ago relating to the general
>> development process. Like many
>> others, we have gotten used to the process where the HTML designers
>> mock up a page and then a
>> software engineer transition the page to a JSP and wires it into our
>> system (using Struts, and
>> JSTL). What is the vision for the development process in JSF?
>>
>> Also, what is the ultimate vision for JSF? Do you invision a IDE
>> that can create interfaces on
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts - Development Process Questions
Posted by Bryan Hunt <ad...@revoltingdigits.com>.
+1
I am sceptical about this technology but potentially it could be good.
I'm going to look at JSF in 6 months
or a years time when it is clearer if this is going to be another
timewaster/project wrecker or something
usefull and useable.
In the meantime I recomend NitroX as well although I don't like the
companys "patent pending" bs about
their "app x ray" technology....
Things like that don't make me particularly enthusiastic as someone who
has to constantly worry about
software patents when I'm writing a LGPL app/using a linux server.
--b
Mike Duffy wrote:
>I have some questions regarding the development process when using JSF, especially in realtion to
>HTML designers. Will everyone on the team need the same advanced design tools? Will the
>designers who are used to tweaking HTML/JSP be restricted to a completely visual drag and drop
>environment? Or even worse, will the HTML designers be required to learn JSF mark up code?
>
>There was another thread a few weeks ago relating to the general development process. Like many
>others, we have gotten used to the process where the HTML designers mock up a page and then a
>software engineer transition the page to a JSP and wires it into our system (using Struts, and
>JSTL). What is the vision for the development process in JSF?
>
>Also, what is the ultimate vision for JSF? Do you invision a IDE that can create interfaces on
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: JSF vs Struts - Development Process Questions
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
At 10:51 AM 7/19/2004, you wrote:
> > If you'd like to see some leading edge Flash, turn up your sound and go to
> > http://www.2advanced.com/
HELLO! Wow!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: JSF vs Struts - Development Process Questions
Posted by Robert Taylor <rt...@mulework.com>.
> If you'd like to see some leading edge Flash, turn up your sound and go to
> http://www.2advanced.com/
That's some pretty cool stuff!
robert
> -----Original Message-----
> From: Mike Duffy [mailto:mduffy_lists@yahoo.com]
> Sent: Monday, July 19, 2004 12:58 PM
> To: Struts Users Mailing List
> Subject: Re: JSF vs Struts - Development Process Questions
>
>
> I have some questions regarding the development process when using JSF, especially in realtion to
> HTML designers. Will everyone on the team need the same advanced design tools? Will the
> designers who are used to tweaking HTML/JSP be restricted to a completely visual drag and drop
> environment? Or even worse, will the HTML designers be required to learn JSF mark up code?
>
> There was another thread a few weeks ago relating to the general development process. Like many
> others, we have gotten used to the process where the HTML designers mock up a page and then a
> software engineer transition the page to a JSP and wires it into our system (using Struts, and
> JSTL). What is the vision for the development process in JSF?
>
> Also, what is the ultimate vision for JSF? Do you invision a IDE that can create interfaces on
> the same level as Flash? A question asked earlier in this thread: Will JSF integrate with Flash
> forms? It would be cool to have one integrated development system that could do it all.
>
> This thread was started with the question, "If you were starting a project today, what would you
> use, Struts or JSF?" My answer is, I would use Struts with JSTL and I would purchase the new
> Eclipse based IDE, NitroX (http://www.m7.com/). We purchased licenses for NitroX after our CTO
> came back from JavaOne. It looks like the creative people at M7 have done a lot of things right;
> they even have planned support for JSF. NitroX may very well evolve into the IDE that can do it
> all. The best thing about NitroX is that it will enable a transition from Struts to JSF if you
> decide to go that route. The main reason I would choose Struts/JSTL over JSF is that it works
> well within the existing skill sets of most developers and designers.
>
> I would keep an open mind regarding JSF, especially in regard to high level components that are
> not easily created using JSP/JSTL. This is the area where JSF could win the game.
>
> In the near term, my guess is that the really cool advanced interfaces are going to require Flash.
> If you'd like to see some leading edge Flash, turn up your sound and go to
> http://www.2advanced.com/
>
> Mike
>
>
>
> --- Michael McGrady <mi...@michaelmcgrady.com> wrote:
> > At 01:01 AM 7/19/2004, you wrote:
> > >The custom tags that Struts provides (in the html and logic and bean
> > >tag libraries) were a necessary precursor to "out of the box" usage of
> > >Struts, in order to make it possible to adopt the basic MVC
> > >architectural pattenrs. However, that was *always* a secondary
> > >feature in the original vision -- the important part was separation of
> > >the view tier logic from the business tier logic.
> > >
> > >Craig McClanahan
> > >(Original creator of the Struts framework)
> >
> >
> > As an original historical matter, it would be hubris of the highest variety
> > to question you on this, Craig. As a historical consequence, however, I
> > for one think that this turned out to be the more revolutionary result of
> > struts, leading coding into taglibs in a way not seen before. The
> > controller and MVC (of sorts) pattern in Struts existed in all sorts of
> > forms prior to Struts. Struts did it better than most, maybe better than
> > all the rest, and provided a standard that people could code to. But,
> > those tags were just a big surprise in the way they hit the market. I, for
> > one, now code tags as readily as I code classes. Not as many, of course,
> > but they are a definite weapon in my quiver. A big reason for that is that
> > I could code using Struts taglib code as a learning and doing mechanism
> > together. Blah, blah, blah. This is not meant to be particularly
> > profound. But I did want to give this boost to the tags in Struts. I
> > think they have been very important to Java.
> >
> > Michael
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
>
> __________________________________
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
> http://advision.webevents.yahoo.com/yahoo/votelifeengine/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts - Development Process Questions
Posted by Mike Duffy <md...@yahoo.com>.
I have some questions regarding the development process when using JSF, especially in realtion to
HTML designers. Will everyone on the team need the same advanced design tools? Will the
designers who are used to tweaking HTML/JSP be restricted to a completely visual drag and drop
environment? Or even worse, will the HTML designers be required to learn JSF mark up code?
There was another thread a few weeks ago relating to the general development process. Like many
others, we have gotten used to the process where the HTML designers mock up a page and then a
software engineer transition the page to a JSP and wires it into our system (using Struts, and
JSTL). What is the vision for the development process in JSF?
Also, what is the ultimate vision for JSF? Do you invision a IDE that can create interfaces on
the same level as Flash? A question asked earlier in this thread: Will JSF integrate with Flash
forms? It would be cool to have one integrated development system that could do it all.
This thread was started with the question, "If you were starting a project today, what would you
use, Struts or JSF?" My answer is, I would use Struts with JSTL and I would purchase the new
Eclipse based IDE, NitroX (http://www.m7.com/). We purchased licenses for NitroX after our CTO
came back from JavaOne. It looks like the creative people at M7 have done a lot of things right;
they even have planned support for JSF. NitroX may very well evolve into the IDE that can do it
all. The best thing about NitroX is that it will enable a transition from Struts to JSF if you
decide to go that route. The main reason I would choose Struts/JSTL over JSF is that it works
well within the existing skill sets of most developers and designers.
I would keep an open mind regarding JSF, especially in regard to high level components that are
not easily created using JSP/JSTL. This is the area where JSF could win the game.
In the near term, my guess is that the really cool advanced interfaces are going to require Flash.
If you'd like to see some leading edge Flash, turn up your sound and go to
http://www.2advanced.com/
Mike
--- Michael McGrady <mi...@michaelmcgrady.com> wrote:
> At 01:01 AM 7/19/2004, you wrote:
> >The custom tags that Struts provides (in the html and logic and bean
> >tag libraries) were a necessary precursor to "out of the box" usage of
> >Struts, in order to make it possible to adopt the basic MVC
> >architectural pattenrs. However, that was *always* a secondary
> >feature in the original vision -- the important part was separation of
> >the view tier logic from the business tier logic.
> >
> >Craig McClanahan
> >(Original creator of the Struts framework)
>
>
> As an original historical matter, it would be hubris of the highest variety
> to question you on this, Craig. As a historical consequence, however, I
> for one think that this turned out to be the more revolutionary result of
> struts, leading coding into taglibs in a way not seen before. The
> controller and MVC (of sorts) pattern in Struts existed in all sorts of
> forms prior to Struts. Struts did it better than most, maybe better than
> all the rest, and provided a standard that people could code to. But,
> those tags were just a big surprise in the way they hit the market. I, for
> one, now code tags as readily as I code classes. Not as many, of course,
> but they are a definite weapon in my quiver. A big reason for that is that
> I could code using Struts taglib code as a learning and doing mechanism
> together. Blah, blah, blah. This is not meant to be particularly
> profound. But I did want to give this boost to the tags in Struts. I
> think they have been very important to Java.
>
> Michael
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
At 01:01 AM 7/19/2004, you wrote:
>The custom tags that Struts provides (in the html and logic and bean
>tag libraries) were a necessary precursor to "out of the box" usage of
>Struts, in order to make it possible to adopt the basic MVC
>architectural pattenrs. However, that was *always* a secondary
>feature in the original vision -- the important part was separation of
>the view tier logic from the business tier logic.
>
>Craig McClanahan
>(Original creator of the Struts framework)
As an original historical matter, it would be hubris of the highest variety
to question you on this, Craig. As a historical consequence, however, I
for one think that this turned out to be the more revolutionary result of
struts, leading coding into taglibs in a way not seen before. The
controller and MVC (of sorts) pattern in Struts existed in all sorts of
forms prior to Struts. Struts did it better than most, maybe better than
all the rest, and provided a standard that people could code to. But,
those tags were just a big surprise in the way they hit the market. I, for
one, now code tags as readily as I code classes. Not as many, of course,
but they are a definite weapon in my quiver. A big reason for that is that
I could code using Struts taglib code as a learning and doing mechanism
together. Blah, blah, blah. This is not meant to be particularly
profound. But I did want to give this boost to the tags in Struts. I
think they have been very important to Java.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 18 Jul 2004 23:40:08 -0600, Jeff Stewart <ks...@elp.rr.com> wrote:
> I've been monitoring this discussion. I for one like using the struts
> html tags over the JSTL/JSF semantically strange tags.
> For one thing, feedback from the HTML developers I work with, prefer
> html:interate this over the {c:jstl } garboono.
I presume you mean <logic:iterate>, not <html:interate> (which doesn't
exist :-).
> I mean, isn't this a big motivation why Struts was created.
No, that's *not* at all why Struts was created.
The primary reason Struts was created was to enable application
developers to employ a web application architecture based on
model-view-controller principles ... in particular, enabling the
separation of the controller tier from the view tier. When Struts was
created, there were no commonly accepted design patterns for that
separation.
The custom tags that Struts provides (in the html and logic and bean
tag libraries) were a necessary precursor to "out of the box" usage of
Struts, in order to make it possible to adopt the basic MVC
architectural pattenrs. However, that was *always* a secondary
feature in the original vision -- the important part was separation of
the view tier logic from the business tier logic.
Craig McClanahan
(Original creator of the Struts framework)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: JSF vs Struts
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
personaly i like the jsf-guys for tables
(<h:dataTable>, <h:panelGrid>)
there is NO need for adding table-specific-html
(eg. <tr><td>) during the loop,
like
<html:iterate....>
<tr><td><bean:write .../></td>...</tr>
</html:iterat>
see
http://www.exadel.com/tutorial/jsf/jsftags-guide.html#column
and
http://www.exadel.com/tutorial/jsf/jsftags-guide.html#panel
same with display-tag (http://displaytag.sf.net) on using struts/jsp,
regards,
matthias
> -----Original Message-----
> From: Jeff Stewart [mailto:ksitron@elp.rr.com]
> Sent: Monday, July 19, 2004 7:40 AM
> To: Struts Users Mailing List
> Subject: Re: JSF vs Struts
>
>
> I've been monitoring this discussion. I for one like using the struts
> html tags over the JSTL/JSF semantically strange tags.
> For one thing, feedback from the HTML developers I work with, prefer
> html:interate this over the {c:jstl } garboono.
> I mean, isn't this a big motivation why Struts was created.
>
> Craig McClanahan wrote:
>
> >On Sun, 18 Jul 2004 23:56:55 -0400, Rick Reumann
> <st...@reumann.net>
> >wrote:
> >
> >
> >>Craig McClanahan wrote:
> >>
> >>
> >>
> >>>For applications you are about to start on, if it is your
> intent to
> >>>use the Struts HTML tags for your view tier, you should
> review that
> >>>decision in the light of the developments of the last few months,
> >>>since the JSF spec went final, to say nothing of the
> availability of
> >>>alternative view tier technologies (XML, Velocity, ...) that work
> >>>with Struts as well. If these tags work for you, that's
> fine ... but
> >>>be aware that you are buying in to a mature technology that is
> >>>unlikely to change much in the future.
> >>>
> >>>
> >>Craig, can you elaborate on this a bit more? I'm confused
> because if
> >>you went with a different front end presentation other than JSP and
> >>Struts HTML form tags, why would it matter that you chose
> Struts HTML
> >>tags for the JSP portion?
> >>
> >>
> >
> >If you choose Struts HTML tags for your presentation, you're
> stuck with
> >what Struts provides. Since Struts has no user interface component
> >model of its own, that has led to a variety of ad hoc solutions for
> >more complicated requirements.
> >
> >If you choose JSF components, not only are you not stuck with what
> >Struts provides (because the JSF API standards are common --
> and there
> >will be ***lots*** of third party components built on top of this
> >standard), you're not stuck with JSP either. See below for more.
> >
> >
> >
> >>If you later chose an XML/XSLT or Velocity
> >>(yuk:)solution for your view you'd end up scrapping the JSPs
> >>altogether anyway so why would it matter what tags you used
> to build
> >>the JSPs that you would be replacing? Or are you basically
> saying to
> >>not even bothr using JSPs for a front end view? (I've seen good
> >>velocity templates and I'll take a *clean* JSP using JSTL and tags
> >>over Velocity any day of the week). Thanks for your
> thoughts and all
> >>your work on Struts, JSF, Tomcat, etc.
> >>
> >>
> >>
> >
> >The Struts HTML tags are very much specific to JSP ... indeed, their
> >very implementation is as instances of JSP custom tags. You
> can't use
> >them at all without buying in to JSP as a display
> technology. And, for
> >various reasons, more than a few loudmouths :-) in the Java
> community
> >do not like JSP at all.
> >
> >With JSF, however, the situation is different. Every JSF
> component is,
> >at its core, just a JavaBean ... it doesn't care what technology is
> >used to ultimately manage the page. Yes, we provide JSP tag
> wrappers
> >around all the standard components (because that addresses
> the need of
> >a very large portion of the marketplace), but it's not
> required. The
> >reason is that JSF provides a pluggable ViewHandler
> implementation ...
> >the default one does RequestDispatcher.forward() calls (just like
> >Struts does), making it very easy to use JSP, but this is by
> no means
> >required.
> >
> >You like Tapestry style separation of the component tree definition
> >from the static HTML text? That's not hard ... go get
> Hans's JSF book
> >and read the last chapter, to get you 80% of the way to a robust
> >ViewHandler solution.
> >
> >Maybe you'd prefer XForms? Go for it ... writing a ViewHandler that
> >transforms your favorite way of representing a component
> tree into an
> >XForms document is MMP (Merely a Matter of Programming :-).
> >
> >Or, maybe you'd prefer an XML based solution that has all
> the component
> >stuff in a single file, and you're contemplating an XSLT
> based solution
> >that transforms component definitions into the corresponding
> HTML. Go
> >for it. (Of, course, if you use the XML syntax for JSP
> pages plus JSF
> >component tags, you get this pretty much for free ... oops, sorry,
> >forgot you might be one of those that doesn't like JSP :-).
> >
> >The basic point is, JSF is not restricted to using JSP as
> the view tier
> >... although, for obvious market share reasons (the number
> of current
> >Java developers that use JSP dwarfs the number that use other view
> >technologies) JSF makes this very easy.
> >
> >
> >
> >>--
> >>Rick
> >>
> >>
> >
> >Craig
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts
Posted by Jeff Stewart <ks...@elp.rr.com>.
I've been monitoring this discussion. I for one like using the struts
html tags over the JSTL/JSF semantically strange tags.
For one thing, feedback from the HTML developers I work with, prefer
html:interate this over the {c:jstl } garboono.
I mean, isn't this a big motivation why Struts was created.
Craig McClanahan wrote:
>On Sun, 18 Jul 2004 23:56:55 -0400, Rick Reumann <st...@reumann.net> wrote:
>
>
>>Craig McClanahan wrote:
>>
>>
>>
>>>For applications you are about to start on, if it is your intent to
>>>use the Struts HTML tags for your view tier, you should review that
>>>decision in the light of the developments of the last few months,
>>>since the JSF spec went final, to say nothing of the availability of
>>>alternative view tier technologies (XML, Velocity, ...) that work with
>>>Struts as well. If these tags work for you, that's fine ... but be
>>>aware that you are buying in to a mature technology that is unlikely
>>>to change much in the future.
>>>
>>>
>>Craig, can you elaborate on this a bit more? I'm confused because if you
>>went with a different front end presentation other than JSP and Struts
>>HTML form tags, why would it matter that you chose Struts HTML tags for
>>the JSP portion?
>>
>>
>
>If you choose Struts HTML tags for your presentation, you're stuck
>with what Struts provides. Since Struts has no user interface
>component model of its own, that has led to a variety of ad hoc
>solutions for more complicated requirements.
>
>If you choose JSF components, not only are you not stuck with what
>Struts provides (because the JSF API standards are common -- and there
>will be ***lots*** of third party components built on top of this
>standard), you're not stuck with JSP either. See below for more.
>
>
>
>>If you later chose an XML/XSLT or Velocity
>>(yuk:)solution for your view you'd end up scrapping the JSPs altogether
>>anyway so why would it matter what tags you used to build the JSPs that
>>you would be replacing? Or are you basically saying to not even bothr
>>using JSPs for a front end view? (I've seen good velocity templates and
>>I'll take a *clean* JSP using JSTL and tags over Velocity any day of the
>>week). Thanks for your thoughts and all your work on Struts, JSF,
>>Tomcat, etc.
>>
>>
>>
>
>The Struts HTML tags are very much specific to JSP ... indeed, their
>very implementation is as instances of JSP custom tags. You can't use
>them at all without buying in to JSP as a display technology. And,
>for various reasons, more than a few loudmouths :-) in the Java
>community do not like JSP at all.
>
>With JSF, however, the situation is different. Every JSF component
>is, at its core, just a JavaBean ... it doesn't care what technology
>is used to ultimately manage the page. Yes, we provide JSP tag
>wrappers around all the standard components (because that addresses
>the need of a very large portion of the marketplace), but it's not
>required. The reason is that JSF provides a pluggable ViewHandler
>implementation ... the default one does RequestDispatcher.forward()
>calls (just like Struts does), making it very easy to use JSP, but
>this is by no means required.
>
>You like Tapestry style separation of the component tree definition
>from the static HTML text? That's not hard ... go get Hans's JSF book
>and read the last chapter, to get you 80% of the way to a robust
>ViewHandler solution.
>
>Maybe you'd prefer XForms? Go for it ... writing a ViewHandler that
>transforms your favorite way of representing a component tree into an
>XForms document is MMP (Merely a Matter of Programming :-).
>
>Or, maybe you'd prefer an XML based solution that has all the
>component stuff in a single file, and you're contemplating an XSLT
>based solution that transforms component definitions into the
>corresponding HTML. Go for it. (Of, course, if you use the XML
>syntax for JSP pages plus JSF component tags, you get this pretty much
>for free ... oops, sorry, forgot you might be one of those that
>doesn't like JSP :-).
>
>The basic point is, JSF is not restricted to using JSP as the view
>tier ... although, for obvious market share reasons (the number of
>current Java developers that use JSP dwarfs the number that use other
>view technologies) JSF makes this very easy.
>
>
>
>>--
>>Rick
>>
>>
>
>Craig
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
Re: JSF vs Struts
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 18 Jul 2004 23:56:55 -0400, Rick Reumann <st...@reumann.net> wrote:
> Craig McClanahan wrote:
>
> > For applications you are about to start on, if it is your intent to
> > use the Struts HTML tags for your view tier, you should review that
> > decision in the light of the developments of the last few months,
> > since the JSF spec went final, to say nothing of the availability of
> > alternative view tier technologies (XML, Velocity, ...) that work with
> > Struts as well. If these tags work for you, that's fine ... but be
> > aware that you are buying in to a mature technology that is unlikely
> > to change much in the future.
>
> Craig, can you elaborate on this a bit more? I'm confused because if you
> went with a different front end presentation other than JSP and Struts
> HTML form tags, why would it matter that you chose Struts HTML tags for
> the JSP portion?
If you choose Struts HTML tags for your presentation, you're stuck
with what Struts provides. Since Struts has no user interface
component model of its own, that has led to a variety of ad hoc
solutions for more complicated requirements.
If you choose JSF components, not only are you not stuck with what
Struts provides (because the JSF API standards are common -- and there
will be ***lots*** of third party components built on top of this
standard), you're not stuck with JSP either. See below for more.
> If you later chose an XML/XSLT or Velocity
> (yuk:)solution for your view you'd end up scrapping the JSPs altogether
> anyway so why would it matter what tags you used to build the JSPs that
> you would be replacing? Or are you basically saying to not even bothr
> using JSPs for a front end view? (I've seen good velocity templates and
> I'll take a *clean* JSP using JSTL and tags over Velocity any day of the
> week). Thanks for your thoughts and all your work on Struts, JSF,
> Tomcat, etc.
>
The Struts HTML tags are very much specific to JSP ... indeed, their
very implementation is as instances of JSP custom tags. You can't use
them at all without buying in to JSP as a display technology. And,
for various reasons, more than a few loudmouths :-) in the Java
community do not like JSP at all.
With JSF, however, the situation is different. Every JSF component
is, at its core, just a JavaBean ... it doesn't care what technology
is used to ultimately manage the page. Yes, we provide JSP tag
wrappers around all the standard components (because that addresses
the need of a very large portion of the marketplace), but it's not
required. The reason is that JSF provides a pluggable ViewHandler
implementation ... the default one does RequestDispatcher.forward()
calls (just like Struts does), making it very easy to use JSP, but
this is by no means required.
You like Tapestry style separation of the component tree definition
from the static HTML text? That's not hard ... go get Hans's JSF book
and read the last chapter, to get you 80% of the way to a robust
ViewHandler solution.
Maybe you'd prefer XForms? Go for it ... writing a ViewHandler that
transforms your favorite way of representing a component tree into an
XForms document is MMP (Merely a Matter of Programming :-).
Or, maybe you'd prefer an XML based solution that has all the
component stuff in a single file, and you're contemplating an XSLT
based solution that transforms component definitions into the
corresponding HTML. Go for it. (Of, course, if you use the XML
syntax for JSP pages plus JSF component tags, you get this pretty much
for free ... oops, sorry, forgot you might be one of those that
doesn't like JSP :-).
The basic point is, JSF is not restricted to using JSP as the view
tier ... although, for obvious market share reasons (the number of
current Java developers that use JSP dwarfs the number that use other
view technologies) JSF makes this very easy.
> --
> Rick
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts
Posted by Rick Reumann <st...@reumann.net>.
Craig McClanahan wrote:
> For applications you are about to start on, if it is your intent to
> use the Struts HTML tags for your view tier, you should review that
> decision in the light of the developments of the last few months,
> since the JSF spec went final, to say nothing of the availability of
> alternative view tier technologies (XML, Velocity, ...) that work with
> Struts as well. If these tags work for you, that's fine ... but be
> aware that you are buying in to a mature technology that is unlikely
> to change much in the future.
Craig, can you elaborate on this a bit more? I'm confused because if you
went with a different front end presentation other than JSP and Struts
HTML form tags, why would it matter that you chose Struts HTML tags for
the JSP portion? If you later chose an XML/XSLT or Velocity
(yuk:)solution for your view you'd end up scrapping the JSPs altogether
anyway so why would it matter what tags you used to build the JSPs that
you would be replacing? Or are you basically saying to not even bothr
using JSPs for a front end view? (I've seen good velocity templates and
I'll take a *clean* JSP using JSTL and tags over Velocity any day of the
week). Thanks for your thoughts and all your work on Struts, JSF,
Tomcat, etc.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 18 Jul 2004 17:04:44 +0200, Bryan Hunt
<ad...@revoltingdigits.com> wrote:
> struts exists and has existed for a long time. jsf is yet another naf
> sun inspired attempt to mimic microsoft.
>
I suspect Bryan might be confusing particular tools (i.e. Sun Java
Studio Creator, deliberately aimed at corporate developers) with the
underlying technology of JSF (which is already being supported across
a wide variety of traditional Java-developer-oriented tools).
In particular, though, you need to understand that Struts and JSF is
not an either-or decision.
http://struts.apache.org/faqs/kickstart.html#jsf
The Struts-Faces integration library mentioned there is proceeding
nicely, and is nearing the point where it's ready for alpha and beta
releases to shake out the remaining bugs. In the mean time, nightly
builds are available at:
http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/
The reference implementation of JSF has been made available on
java.net for open development:
https://javaserverfaces.dev.java.net/
In addition, there is an open source implementation under way
(MyFaces) that started at SourceForge:
http://sourceforge.net/projects/myfaces/
but has just been accepted into incubation at Apache -- website isn't
up yet, but when it is, it will be at:
http://incubator.apache.org/myfaces/
with the goal of a JSF implementation that has passed the compliance
tests, available under the Apache License (just like Struts and
Tomcat).
Finally, a historical note. I (as original creator of Struts) have
been stating for over a year now that the majority of Struts
developers consider the Struts HTML tag library to be legacy code --
we'll continue to support it by committing bugfixes, but you are
unlikely to see much innovation happening there (unless, of course,
new developers step up to the plate and want to work here). For
legacy Struts-based applications (or applications being developed
now), the Struts-Faces library will make it very easy to migrate, one
page at a time, to JSF -- *if* you need the extra functionality that
comes from a world of third party components all programmed to the
same API standard.
For applications you are about to start on, if it is your intent to
use the Struts HTML tags for your view tier, you should review that
decision in the light of the developments of the last few months,
since the JSF spec went final, to say nothing of the availability of
alternative view tier technologies (XML, Velocity, ...) that work with
Struts as well. If these tags work for you, that's fine ... but be
aware that you are buying in to a mature technology that is unlikely
to change much in the future.
> --b
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: JSF vs Struts
Posted by Bryan Hunt <ad...@revoltingdigits.com>.
struts exists and has existed for a long time. jsf is yet another naf
sun inspired attempt to mimic microsoft.
--b
Martin Gainty wrote:
>Sorry for the simplistic question
>Starting a new project and trying to get a handle on 2 different approaches
>What does Struts have to offer over JSF?
>Thanks,
>martin
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
JSF vs Struts
Posted by Martin Gainty <mg...@hotmail.com>.
Sorry for the simplistic question
Starting a new project and trying to get a handle on 2 different approaches
What does Struts have to offer over JSF?
Thanks,
martin
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts Sample / Best Practices for Database access
Posted by Ted Husted <hu...@apache.org>.
This is kind of a trick question, or at least a trick subject.
In a Struts application, the best practice for database access is for Struts to be unaware that there is even such a thing as a database. If you are using the Struts best practice, then it shouldn't matter whether the database example is in a Struts application or not.
The Struts Mailreader demonstrates an excellent practice for database access. It defines an POJO interface with the methods that accept and/or return the data that the application needs. The Actions expect that singleton instances of these plain-old Java objects will be in application scope under a known name. The Actions speak only to the interface. A Struts PlugIn loads an implementation of the interfaces into application scope under the expected names, and we are ready to rock.
The POJO JavaBeans can be implemented using whatever technology you like. They should not know there are living in a Struts application, or even a Web application, and should be fully testable. You should be able to write them using stock examples for your chosen technology, blissfully unaware of whether they will be used by Struts or not.
-Ted.
On Thu, 15 Jul 2004 14:16:29 +0800, Richard Reyes wrote:
>�Hi Guys,
>
>�Newbie question, where can i get struts sample application using
>�database components like DAO, JDO or Hibernate samples.
>
>�Thanks
>�Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org