You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ryan Wynn <rw...@us.ibm.com> on 2005/08/15 18:15:58 UTC
Choosing Tapestry
I have been using Tapestry 4.0 for 2 weeks now for portlet development and
I can say my experience has been very positive. I have found that my
tapestry portlets have come out much much cleaner than their JSF
counterparts. I think the ability to inject pages and hivemend services
really makes for an elegant design. Not only that but the line precise
error reporting probably saved me hours of debugging (My mistakes in JSF
JSPs get wrapped in very obscure ClassCastExceptions in the logs).
However, I am tasked with choosing a framework for my client and although
Tapestry appeals to me it may not be right for this project. It seems to
me that with Facelets JSF is transforming more and more into Tapestry. JSF
tooling in WSAD (which is the project IDE) comes out of the box and is
further along than Spindle in the portlet arena. Also, the project uses
applets quite extensively. From what I have read about Facelets I can
leverage JSF outside of a web container with Swing or SWT.
Is there anything fundamentally stopping JSF (the "standard" + all that
standard implies, e.g. it's not hard to hire a Struts expert) from
stealing the best parts of Tapestry (line precise error/templating to
start) and making me look like a fool for choosing Tapestry a couple years
from now?
Thanks,
Ryan
=======================================
Ryan Wynn
Websphere Portal Developer
IBM Business Consulting Services - Public Sector
Reston Office: 703-668-2478
Cell: 703-622-1977
rwynn@us.ibm.com
Re: Choosing Tapestry
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
--- Jacob Hookom <ja...@hookom.net> wrote:
>
> JSF works on the command pattern, so you set state
> as
> instance variables on a model object and then be
> able
> to call methods on it. When you talk about
> parameter
> passing, then you are dealing with transient
> variables
> that only exist in the invocation scope.
>
> While this is now do-able with JSF 1.2 (in a
> different
> way than Tapestry), having models retain parameter
> information (as is implied) offers an opportunity
> that is
> more attuned to view lifecycles within rich-ui
> applications
> and state management.
>
> component do whatever, but simply point it at
> #{searchResult.page}
> and let JSF do the work for you. Again, it's a
> different concept
> than maybe what's promoted with Tapestry. But you
> can't use the above
> as an argument against JSF when actually it should
> be handled in
> a completely different way.
>
What exactly the code you would suggest to use for
selecting an item in the list of results and opening
second page to edit the selected object?
To clarify: the list has a short version of the
object in question ( id+ label ).
> >
> > What the heck!? Is this friendly and convenient
> API?
> >
> > JSF Configuration file, just look at that:
> >
> > <managed-bean>
> >
> >
> <managed-bean-name>globalOptions</managed-bean-name>
> >
> >
> What is that above example? JSF works with POJOs
> (see last comment) and while
> JSF's managed bean XML markup is a little lengthy,
> you always have the option to
> use Hivemind or Spring behind JSF or use all 3
> together.
Oh man! It looks like you think that descriptor is OK.
<managed-bean>
<managed-bean-name>globalOptions</managed-bean-name>
It is not. It should be:
<managed-bean>
<name>globalOptions</name>
> >
> > PS: Hope I will have time this week and add
> > documentation to my comparison and publish it.
>
> Please don't.
What are you afraid of?
I have had experience with the technology based on
whatever I had (including my stupidity). And I am not
afraid to expose all that. Just accept the fact that
people see and perceive things differently learn
from it.
> Or if you do, please run it by
> someone from the the JSF EG to
> clarify any points. I think it would also put more
> leverage behind any arguments you bring up.
>
Why should I? The point of my comparison is to show
what an average Joe like me would try to do with the
technology based on information available ( I even
spent $49.95+tax of my own money to buy JSF in action
because I hoped it would help).
I welcome any critique.
PS: I forgot to suggest the curriculum: Books and
other publications by Don Norman
http://www.jnd.org/
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Jacob Hookom <ja...@hookom.net>.
> Konstantin Ignatyev <kgignatyev <at> yahoo.com> writes:
Apologies for participating the tapestry-user list, but
those comments get publically cycled into google for 'JSF' too :-)
My comments are below:
> What can I say: JSF is horrible! Tapestry has a
> learning curve, but JSF one was horrifying. I bought
> Kito Manns book JSF in Action and it is mind blowing
> how cumbersome simple things are:
> JSF documentation is awkward and incomplete;
> Lets take parameters for example, simple thing a
> parametrized command link:
JSF works on the command pattern, so you set state as
instance variables on a model object and then be able
to call methods on it. When you talk about parameter
passing, then you are dealing with transient variables
that only exist in the invocation scope.
While this is now do-able with JSF 1.2 (in a different
way than Tapestry), having models retain parameter
information (as is implied) offers an opportunity that is
more attuned to view lifecycles within rich-ui applications
and state management.
>
> 2nd accessing parameters mind blowing IMO:
> from Kitos book examples:
>
> public void doIt(ActionEvent actionEvent) {
> String param = null;
> List children =
> actionEvent.getComponent().getChildren();
> for (int i = 0; i < children.size(); i++) {
> if (children.get(i) instanceof UIParameter) {
> UIParameter currentParam = (UIParameter)
> children.get(i);
> if (currentParam.getName().equals("param") &&
> currentParam.getValue() != null) {
> param = currentParam.getValue().toString();
> break;
> }
> }
> }
> FacesContext context =
> FacesContext.getCurrentInstance();
> String id =
> actionEvent.getComponent().getClientId(context);
> System.out.println("In doIt(), component id:
> "+id+", param: "+param);
> }
JSF 'forces' a greater degree of separation between the UI
components and your business logic for the reasons above :-)
I don't think it's worth getting caught up in trying to
accomplish things like that when really, JSF components
are meant to bind state to POJO beans. So let the parameter
component do whatever, but simply point it at #{searchResult.page}
and let JSF do the work for you. Again, it's a different concept
than maybe what's promoted with Tapestry. But you can't use the above
as an argument against JSF when actually it should be handled in
a completely different way.
>
> What the heck!? Is this friendly and convenient API?
>
> JSF Configuration file, just look at that:
>
> <managed-bean>
>
> <managed-bean-name>globalOptions</managed-bean-name>
>
>
<managed-bean-class>com.sourcelabs.demo.webapp.web.jsf.GlobalOptions
</managed-bean-class>
> <managed-bean-scope>session</managed-bean-scope>
> <managed-property>
> <property-name>pageLayout</property-name>
> <value>classic</value>
> </managed-property>
> </managed-bean>
>
> Hey guys, have you ever heard about object
> orientation? It looks ridiculous, same way as object
> like
> Class Person{
> String personFirstName;
> String personLastName;
> String personAge;
> }
>
> Cmon JSF guys, get back to school -school year is
> about to begin!
What is that above example? JSF works with POJOs (see last comment) and while
JSF's managed bean XML markup is a little lengthy, you always have the option to
use Hivemind or Spring behind JSF or use all 3 together.
>
> PS: Hope I will have time this week and add
> documentation to my comparison and publish it.
Please don't. Or if you do, please run it by someone from the the JSF EG to
clarify any points. I think it would also put more leverage behind any
arguments you bring up.
-- Jacob
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Glen Stampoultzis <gs...@iinet.net.au>.
>PS: Hope I will have time this week and add
>documentation to my comparison and publish it.
>
>
>Konstantin Ignatyev
>
>
Hope you have time. I'd be very interested in a detailed comparison.
Wouldn't hurt to show comparisons on the Tapestry website come to think
of it.
Regards,
Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
>, it's worth noting that just a few
> weeks ago, already
> knowing Struts & JSP, I spent four or five days
> experimenting with
> JSF, found it cumbersome and unsatisfying, tried
> Tapestry instead,
That is pretty much my experience with JSF too. I
recently built comparison application to try out
Tapestry;
Struts+Tiles;
Struts+SiteMesh;
JSF(MyFaces);
With exactly the same backend (Hibernate under
Spring).
What can I say: JSF is horrible! Tapestry has a
learning curve, but JSF one was horrifying. I bought
Kito Manns book JSF in Action and it is mind blowing
how cumbersome simple things are:
JSF documentation is awkward and incomplete;
Lets take parameters for example, simple thing a
parametrized command link:
<h:commandLink
actionListener="#{companyCRUDForm.show}"
action="crud"
immediate="true"
value="show">
<f:param name="id"
value="#{c.id}"/>
</h:commandLink>
1st we cannot call parameterized function- it is
non-argument navigation function, or action listener
that takes ActionEvent, but we cannot control
navigation from the listener, therefore we have
awkward combination of actionListener parameter that
invokes function where we do stuff, and action
parameter that allows navigation.
2nd accessing parameters mind blowing IMO:
from Kitos book examples:
public void doIt(ActionEvent actionEvent) {
String param = null;
List children =
actionEvent.getComponent().getChildren();
for (int i = 0; i < children.size(); i++) {
if (children.get(i) instanceof UIParameter) {
UIParameter currentParam = (UIParameter)
children.get(i);
if (currentParam.getName().equals("param") &&
currentParam.getValue() != null) {
param = currentParam.getValue().toString();
break;
}
}
}
FacesContext context =
FacesContext.getCurrentInstance();
String id =
actionEvent.getComponent().getClientId(context);
System.out.println("In doIt(), component id:
"+id+", param: "+param);
}
What the heck!? Is this friendly and convenient API?
JSF Configuration file, just look at that:
<managed-bean>
<managed-bean-name>globalOptions</managed-bean-name>
<managed-bean-class>com.sourcelabs.demo.webapp.web.jsf.GlobalOptions</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<property-name>pageLayout</property-name>
<value>classic</value>
</managed-property>
</managed-bean>
Hey guys, have you ever heard about object
orientation? It looks ridiculous, same way as object
like
Class Person{
String personFirstName;
String personLastName;
String personAge;
}
Cmon JSF guys, get back to school -school year is
about to begin!
PS: Hope I will have time this week and add
documentation to my comparison and publish it.
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Paul Cantrell <ca...@pobox.com>.
>> A more plausible case is many different UIs, designed differently to
>> fit their medium, sharing the same back end. JSF won't help you with
>> that any more than any other framework.
>
> Are you sure about that one? JSF opens up a horizontal market for
> vendors and
> open source developers such that there's a much higher degree of re-
> use and
> collaboration allowed in the request stack.
Yes, I am sure. What I'm skeptical about is whether components built
on the JSF model will make good rich GUI apps. The reason one writes
a Swing app is to take advantage of exactly the sorts of things that
JSF abstracts away (e.g. a fully asynchronous event model -- and
please don't try to tell me that JSF has one). I have yet to be
convinced that JSF can actually be used to build a Swing application
that doesn't feel like a usability hoax.
I am probably ignorant and completely off-base, but discussion isn't
likely to convince me. What's needed is some examples that prove me
wrong. Show me an awesome rich GUI app with a tidy codebase written
with JSF, and I'll be convinced.
>> In short, none of us have a crystal ball that you don't.
>
> My eight-ball tells me otherwise.
So I noticed! You are clearly a JSF True Believer. And to your
credit, Facelets are clearly thinking about the developer usability
issues that currently make JSF cumbersome to work with.
I'm not a true believer in JSF, Tapestry, or any other existing web
framework, and I don't spend much time looking into 8-balls. But on a
practical note, it's worth noting that just a few weeks ago, already
knowing Struts & JSP, I spent four or five days experimenting with
JSF, found it cumbersome and unsatisfying, tried Tapestry instead,
liked it, and chose it for my current project. And even though the
skills I'm acquiring won't help me build telnet applications, I still
somehow manage to sleep soundly at night.
Cheers,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Jacob Hookom <ja...@hookom.net>.
Paul Cantrell <cantrell <at> pobox.com> writes:
>
> (1) Is anybody actually doing this? Do any stable frameworks actually
> exist that support it?
MyFaces has WML support and Oracle's ADF component library can be be used within
WML, HTML, and even *telnet*. Scary...
>
> (2) Is it something you actually *want* to do?
You are missing the point of JSF as a standard. Having a lot of developers
familiar with a platform that can be used to write applications for HTML, WML,
telnet, Swing, Laszlo--. I don't think JSF's intentions are to use the same
'application' for all of those mediums, but be able to use the same 'platform'
for all mediums.
>
> A more plausible case is many different UIs, designed differently to
> fit their medium, sharing the same back end. JSF won't help you with
> that any more than any other framework.
Are you sure about that one? JSF opens up a horizontal market for vendors and
open source developers such that there's a much higher degree of re-use and
collaboration allowed in the request stack. So if your group chooses JSF,
adapting to different needs such as reporting, rich tabular data, delivering to
different platforms... yeah, JSF will help you more than other frameworks.
>
> In short, none of us have a crystal ball that you don't.
My eight-ball tells me otherwise. As bloated as JSF is, instead of everyone
writing frameworks on top of the servlet spec, it says it's "most inevitable"
that developers and projects will be customizing frameworks on top of JSF.
All the Best,
Jacob
>
> Cheers,
>
> Paul
>
> _________________________________________________________________
>
> "Verbing weirds language." -- Bill Watterson
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe <at> jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help <at> jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Choosing Tapestry
Posted by Patrick Casey <pa...@adelphia.net>.
> (2) Is it something you actually *want* to do? UIs gets designed
> *very* differently for web vs. mobile vs. rich client GUI. The
> layout, workflow, and behavior that makes sense for a web app won't
> necessarily work nicely on a cell phone -- and a JSF app designed for
> the web and rendered as Swing will feel like ... well, like a web
> page rendered with Swing. What's the advantage of that? You can just
> as easily ember a Swing web browser and reuse a web interface written
> with any web framework. If you want a rich client, you'll want to
> design it that way. So I'm not convinced that this is a problem
> anybody actually has.
A number of years ago (ok, like 4), I was involved in a pretty high
level project with a lot of very smart people trying to solve that
particular problem e.g. design a meta-UI definition that would produce a
rich client look and feel in a rich client, and a comparably useable webby
client in a web browser.
It must have eaten like 5 man years of design work, prototypes and
untold blind alleys. Basically, what we were forced to do is design a rich
client app and then try to define rules so that it failed gracefully as the
client gets less and less capable.
The problem was that nothing sufficiently complex to offer a good
rich client experience failed particularly gracefully no matter how much
time and effort we put into the "fail over" routines. We could always make
any given special case fail well, so we could always whip up a slick looking
*demo* the problem was every demo was its own discrete special case.
Anyway, I, like you, am very suspicious of any framework which
claims to take the same meta-definition and run *well* in a variety of
discrete client platforms.
--- Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Paul Cantrell <ca...@pobox.com>.
> I have found that my tapestry portlets have come out much much
> cleaner than their JSF
> counterparts.
That has been exactly my experience as well, after a similar (if
rather casual) comparison. JSF is promising, though.
> From what I have read about Facelets I can leverage JSF outside of
> a web container with Swing or SWT.
That's certainly one of JSF's design goals, but I wonder:
(1) Is anybody actually doing this? Do any stable frameworks actually
exist that support it?
(2) Is it something you actually *want* to do? UIs gets designed
*very* differently for web vs. mobile vs. rich client GUI. The
layout, workflow, and behavior that makes sense for a web app won't
necessarily work nicely on a cell phone -- and a JSF app designed for
the web and rendered as Swing will feel like ... well, like a web
page rendered with Swing. What's the advantage of that? You can just
as easily ember a Swing web browser and reuse a web interface written
with any web framework. If you want a rich client, you'll want to
design it that way. So I'm not convinced that this is a problem
anybody actually has.
A more plausible case is many different UIs, designed differently to
fit their medium, sharing the same back end. JSF won't help you with
that any more than any other framework.
> Is there anything fundamentally stopping JSF (the "standard" + all
> that
> standard implies) ... making me look like a fool for choosing
> Tapestry a couple years
> from now?
No -- nor is there anything stopping JSF from dying on the vine. I
like JDO a lot, but Hibernate seems to have eclipsed it, at least for
now -- even though it is a "standard" and all that implies.
In short, none of us have a crystal ball that you don't.
Cheers,
Paul
_________________________________________________________________
"Verbing weirds language." -- Bill Watterson
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Jan Vissers <Ja...@cumquat.nl>.
Jacob,
I've noticed you're really busy trying to get the 'facelet' message across.
http://www.theserverside.com/news/thread.tss?thread_id=35900
http://www.theserverside.com/news/thread.tss?thread_id=35900
http://jroller.com/page/RickHigh?entry=facelets_aims_jsf_at_tapestry
http://raibledesigns.com/page/rd?anchor=taming_jsf_1_1
Personally I think it's a good thing JSF is competing with Tapestry as
it will make
both approaches better. At the moment however Tapestry is clearly in the
lead,
especially with the new stuff in 4.0 and it looks like the community is
growing rapidly.
We'll have to wait and see whether JSF will be as 'successful' as EJB
Entity Beans,
also a *standard*. To me lasting results for my customers are more
important
than standards per se.
-J.
Jacob Hookom wrote:
>>On 8/15/05, Ryan Wynn <rwynn <at> us.ibm.com> wrote:
>>
>>
>
>It's quite obvious that Facelets can 'cast' a HTML element into a component, but
>it handles it a little differently than Tapestry where everything stays strict
>XML w/ namespaces. In addition, Facelet's JSFC attribute only handles half of
>the equation, relying on a separate JSF-standard 'binding' attribute. Clay is
>trying to to a straight copy of Tapestry, even going as far as using Tapestry's
>parser.
>
>Truthfully, I don't even like Tapestry's approach for 'casting' HTML elements in
>the page as the 'standard'. It's not the point of Facelets, only a feature that
>I added to appeal to the Tapestry users who complained about JSP as the reason
>not to pursue JSF.
>
>http://weblogs.java.net/blog/jhook/archive/2005/07/programmer_frie_1.html
>
>
>
>>>Also, the project uses
>>>applets quite extensively. From what I have read about Facelets I can
>>>leverage JSF outside of a web container with Swing or SWT.
>>>
>>>
>
>Facelets API is really simple and can be embeded into any kind of portlet
>environment or even a desktop deployment. The point of Facelets is that
>developers go through enough work writing applications that they shouldn't need
>to worry about view-integration issues between JSP and JSF.
>
>
>
>>But how well does it work with Facelets? The tool integration is all
>>about the JSP view. Use a non-JSP view and most of the utility of the
>>tools dissappears.
>>
>>
>
>I really could care less about tooling.
>
>
>
>>Thanks! And thanks to McKesson Provider Technologies for funding this
>>aspect of Tapestry 4.0.
>>
>>
>
>Funny you keep on mentioning McKesson, I actually work in the med-surg division
>in Minneapolis. The company is so big that no body knows anyone else or has
>even heard of many of the other divisions and big enough to name drop.
>
>As for the rest of JSF's stack... you should see some of the projects coming
>from Oracle, JBoss, Apache, and Sun for use with JSF-- Facelets is only one
>piece of the equation. At this point I really wish I could share more about
>some of the new projects coming out, but just keep your eyes peeled for some
>unbelieveable (standard) features that can make development *so* easy.
>
>-- Jacob Hookom
>
>
>Howard Lewis Ship <hlship <at> gmail.com> writes:
>
>
>
>
>
>
>>>I have been using Tapestry 4.0 for 2 weeks now for portlet development and
>>>I can say my experience has been very positive. I have found that my
>>>tapestry portlets have come out much much cleaner than their JSF
>>>counterparts.
>>>
>>>
>
>
>
>>> I think the ability to inject pages and hivemend services
>>>really makes for an elegant design. Not only that but the line precise
>>>error reporting probably saved me hours of debugging (My mistakes in JSF
>>>JSPs get wrapped in very obscure ClassCastExceptions in the logs).
>>>
>>>However, I am tasked with choosing a framework for my client and although
>>>Tapestry appeals to me it may not be right for this project. It seems to
>>>me that with Facelets JSF is transforming more and more into Tapestry. JSF
>>>tooling in WSAD (which is the project IDE) comes out of the box and is
>>>further along than Spindle in the portlet arena.
>>>
>>>
>
>
>
>
>
>
>>Tapestry is so rich that, at first glance, Facelets does appear to
>>steal some of its better ideas. However, once you use Tapestry a bit
>>longer, you realize that the core strengths are not limited to the
>>templates. The injection model in 4.0 (which could be "faked" in
>>3.0), the extensibility via HiveMind, the JavaScript generation, the
>>localization support, and the whole approach at all levels to managing
>>state .... these are very much part of Tapestry too, and harder to
>>grasp immediately, and harder for JSF to replicate.
>>
>>
>>
>>>Is there anything fundamentally stopping JSF (the "standard" + all that
>>>standard implies, e.g. it's not hard to hire a Struts expert) from
>>>stealing the best parts of Tapestry (line precise error/templating to
>>>start) and making me look like a fool for choosing Tapestry a couple years
>>>from now?
>>>
>>>
>>Let's say everything you say might happen does come about. Well, then
>>your Tapestry skills will translate directly into JSF/Facelet skills,
>>and porting your application will be easy. Alternately, getting people
>>with JSF/Facelet skills will be easy, and they'll quickly adapt to the
>>"identical" Tapestry environment.
>>
>>
>>
>>>Thanks,
>>>Ryan
>>>
>>>=======================================
>>>Ryan Wynn
>>>Websphere Portal Developer
>>>IBM Business Consulting Services - Public Sector
>>>Reston Office: 703-668-2478
>>>Cell: 703-622-1977
>>>rwynn <at> us.ibm.com
>>>
>>>
>>>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
--
Cumquat Information Technology
De Dreef 19
3706 BR Zeist
T +31 (0)30 - 6940490
F +31 (0)10 - 6940499
http://www.cumquat.nl
Jan.Vissers@cumquat.nl
M +31 6 5 11 169 556
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Jesse Kuhnert <jk...@gmail.com>.
So it appears that you have ~tried~ to copy some of the core benefits
of tapestry, but ~failed~ to get all the other parts right? Like
injection? Ease of use? etc.. And the fact that JSF is hated for a lot
more than just JSP syntax? God, I was actually sort of thinking that
you had some real cool new stuff until I went and read the
introduction manual...(always one to use the best technology :) ) It's
quite un-compelling, for the same reasons most of the other specs it
is based on were.
I do like your new error reporter, but wouldn't in a million years
want to build a web application based on that specification. It would
be like going back to struts, or servlets with template parsers. Ick .
And why on earth are you mentioning your importance in mckesson? What
point does proving that a big company has problems communicating
prove? Maybe I'm being hostile because you work in a division that
competes with my employer, even though we have the best product on the
market for what we do, which is probably why I love tapestry.
Though, it's funny that I did hear a couple of other very large
companies are kind of working on dev projects using tapestry. I'm not
sure, but I kind of am very super sure that GE and siemens both are.
And since when did it become important that companies like oracle and
the like are using a product? Have you used oracle's appserver? It's a
piece of crap. Yay, out of the thousands and thousands of developers
they have someone is using it .yay.. (don't get me wrong, their
database is awesome, but I'm pretty sure a different sort of dev group
does that kind of work ;) )...
jesse kuhnert
On 8/16/05, Jacob Hookom <ja...@hookom.net> wrote:
> > On 8/15/05, Ryan Wynn <rwynn <at> us.ibm.com> wrote:
>
> It's quite obvious that Facelets can 'cast' a HTML element into a component, but
> it handles it a little differently than Tapestry where everything stays strict
> XML w/ namespaces. In addition, Facelet's JSFC attribute only handles half of
> the equation, relying on a separate JSF-standard 'binding' attribute. Clay is
> trying to to a straight copy of Tapestry, even going as far as using Tapestry's
> parser.
>
> Truthfully, I don't even like Tapestry's approach for 'casting' HTML elements in
> the page as the 'standard'. It's not the point of Facelets, only a feature that
> I added to appeal to the Tapestry users who complained about JSP as the reason
> not to pursue JSF.
>
> http://weblogs.java.net/blog/jhook/archive/2005/07/programmer_frie_1.html
>
> > > Also, the project uses
> > > applets quite extensively. From what I have read about Facelets I can
> > > leverage JSF outside of a web container with Swing or SWT.
>
> Facelets API is really simple and can be embeded into any kind of portlet
> environment or even a desktop deployment. The point of Facelets is that
> developers go through enough work writing applications that they shouldn't need
> to worry about view-integration issues between JSP and JSF.
>
> > But how well does it work with Facelets? The tool integration is all
> > about the JSP view. Use a non-JSP view and most of the utility of the
> > tools dissappears.
>
> I really could care less about tooling.
>
> > Thanks! And thanks to McKesson Provider Technologies for funding this
> > aspect of Tapestry 4.0.
>
> Funny you keep on mentioning McKesson, I actually work in the med-surg division
> in Minneapolis. The company is so big that no body knows anyone else or has
> even heard of many of the other divisions and big enough to name drop.
>
> As for the rest of JSF's stack... you should see some of the projects coming
> from Oracle, JBoss, Apache, and Sun for use with JSF-- Facelets is only one
> piece of the equation. At this point I really wish I could share more about
> some of the new projects coming out, but just keep your eyes peeled for some
> unbelieveable (standard) features that can make development *so* easy.
>
> -- Jacob Hookom
>
>
> Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> >
>
> > > I have been using Tapestry 4.0 for 2 weeks now for portlet development and
> > > I can say my experience has been very positive. I have found that my
> > > tapestry portlets have come out much much cleaner than their JSF
> > > counterparts.
> >
>
> >
> > > I think the ability to inject pages and hivemend services
> > > really makes for an elegant design. Not only that but the line precise
> > > error reporting probably saved me hours of debugging (My mistakes in JSF
> > > JSPs get wrapped in very obscure ClassCastExceptions in the logs).
> > >
> > > However, I am tasked with choosing a framework for my client and although
> > > Tapestry appeals to me it may not be right for this project. It seems to
> > > me that with Facelets JSF is transforming more and more into Tapestry. JSF
> > > tooling in WSAD (which is the project IDE) comes out of the box and is
> > > further along than Spindle in the portlet arena.
> >
>
> >
>
> >
> > Tapestry is so rich that, at first glance, Facelets does appear to
> > steal some of its better ideas. However, once you use Tapestry a bit
> > longer, you realize that the core strengths are not limited to the
> > templates. The injection model in 4.0 (which could be "faked" in
> > 3.0), the extensibility via HiveMind, the JavaScript generation, the
> > localization support, and the whole approach at all levels to managing
> > state .... these are very much part of Tapestry too, and harder to
> > grasp immediately, and harder for JSF to replicate.
> >
> > >
> > > Is there anything fundamentally stopping JSF (the "standard" + all that
> > > standard implies, e.g. it's not hard to hire a Struts expert) from
> > > stealing the best parts of Tapestry (line precise error/templating to
> > > start) and making me look like a fool for choosing Tapestry a couple years
> > > from now?
> >
> > Let's say everything you say might happen does come about. Well, then
> > your Tapestry skills will translate directly into JSF/Facelet skills,
> > and porting your application will be easy. Alternately, getting people
> > with JSF/Facelet skills will be easy, and they'll quickly adapt to the
> > "identical" Tapestry environment.
> >
> > >
> > > Thanks,
> > > Ryan
> > >
> > > =======================================
> > > Ryan Wynn
> > > Websphere Portal Developer
> > > IBM Business Consulting Services - Public Sector
> > > Reston Office: 703-668-2478
> > > Cell: 703-622-1977
> > > rwynn <at> us.ibm.com
> > >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Jacob Hookom <ja...@hookom.net>.
> On 8/15/05, Ryan Wynn <rwynn <at> us.ibm.com> wrote:
It's quite obvious that Facelets can 'cast' a HTML element into a component, but
it handles it a little differently than Tapestry where everything stays strict
XML w/ namespaces. In addition, Facelet's JSFC attribute only handles half of
the equation, relying on a separate JSF-standard 'binding' attribute. Clay is
trying to to a straight copy of Tapestry, even going as far as using Tapestry's
parser.
Truthfully, I don't even like Tapestry's approach for 'casting' HTML elements in
the page as the 'standard'. It's not the point of Facelets, only a feature that
I added to appeal to the Tapestry users who complained about JSP as the reason
not to pursue JSF.
http://weblogs.java.net/blog/jhook/archive/2005/07/programmer_frie_1.html
> > Also, the project uses
> > applets quite extensively. From what I have read about Facelets I can
> > leverage JSF outside of a web container with Swing or SWT.
Facelets API is really simple and can be embeded into any kind of portlet
environment or even a desktop deployment. The point of Facelets is that
developers go through enough work writing applications that they shouldn't need
to worry about view-integration issues between JSP and JSF.
> But how well does it work with Facelets? The tool integration is all
> about the JSP view. Use a non-JSP view and most of the utility of the
> tools dissappears.
I really could care less about tooling.
> Thanks! And thanks to McKesson Provider Technologies for funding this
> aspect of Tapestry 4.0.
Funny you keep on mentioning McKesson, I actually work in the med-surg division
in Minneapolis. The company is so big that no body knows anyone else or has
even heard of many of the other divisions and big enough to name drop.
As for the rest of JSF's stack... you should see some of the projects coming
from Oracle, JBoss, Apache, and Sun for use with JSF-- Facelets is only one
piece of the equation. At this point I really wish I could share more about
some of the new projects coming out, but just keep your eyes peeled for some
unbelieveable (standard) features that can make development *so* easy.
-- Jacob Hookom
Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> > I have been using Tapestry 4.0 for 2 weeks now for portlet development and
> > I can say my experience has been very positive. I have found that my
> > tapestry portlets have come out much much cleaner than their JSF
> > counterparts.
>
>
> > I think the ability to inject pages and hivemend services
> > really makes for an elegant design. Not only that but the line precise
> > error reporting probably saved me hours of debugging (My mistakes in JSF
> > JSPs get wrapped in very obscure ClassCastExceptions in the logs).
> >
> > However, I am tasked with choosing a framework for my client and although
> > Tapestry appeals to me it may not be right for this project. It seems to
> > me that with Facelets JSF is transforming more and more into Tapestry. JSF
> > tooling in WSAD (which is the project IDE) comes out of the box and is
> > further along than Spindle in the portlet arena.
>
>
>
> Tapestry is so rich that, at first glance, Facelets does appear to
> steal some of its better ideas. However, once you use Tapestry a bit
> longer, you realize that the core strengths are not limited to the
> templates. The injection model in 4.0 (which could be "faked" in
> 3.0), the extensibility via HiveMind, the JavaScript generation, the
> localization support, and the whole approach at all levels to managing
> state .... these are very much part of Tapestry too, and harder to
> grasp immediately, and harder for JSF to replicate.
>
> >
> > Is there anything fundamentally stopping JSF (the "standard" + all that
> > standard implies, e.g. it's not hard to hire a Struts expert) from
> > stealing the best parts of Tapestry (line precise error/templating to
> > start) and making me look like a fool for choosing Tapestry a couple years
> > from now?
>
> Let's say everything you say might happen does come about. Well, then
> your Tapestry skills will translate directly into JSF/Facelet skills,
> and porting your application will be easy. Alternately, getting people
> with JSF/Facelet skills will be easy, and they'll quickly adapt to the
> "identical" Tapestry environment.
>
> >
> > Thanks,
> > Ryan
> >
> > =======================================
> > Ryan Wynn
> > Websphere Portal Developer
> > IBM Business Consulting Services - Public Sector
> > Reston Office: 703-668-2478
> > Cell: 703-622-1977
> > rwynn <at> us.ibm.com
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Norbert Sándor <de...@erinors.com>.
This is a clever argument :))))
> Let's say everything you say might happen does come about. Well, then
> your Tapestry skills will translate directly into JSF/Facelet skills,
> and porting your application will be easy. Alternately, getting people
> with JSF/Facelet skills will be easy, and they'll quickly adapt to the
> "identical" Tapestry environment.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Ryan Wynn <rw...@us.ibm.com>.
> But how well does it work with Facelets? The tool integration is all
> about the JSP view. Use a non-JSP view and most of the utility of the
> tools dissappears.
You're right I was only referring to JSF support in jsps. Also, the
plugin for JSF in WSAD does something that is often counter-productive.
When you add a UI component to a jsp the plugin automatically adds a
getter method to the backing java class. This leads to alot of useless
code clutter and is one reason why the tapestry portlets were much
cleaner. This of course is the tool and not JSF.
> Let's say everything you say might happen does come about. Well, then
> your Tapestry skills will translate directly into JSF/Facelet skills,
> and porting your application will be easy. Alternately, getting people
> with JSF/Facelet skills will be easy, and they'll quickly adapt to the
> "identical" Tapestry environment.
I am actually evaluating frameworks now because this project used/uses an
in-house web framework very similiar to Struts. It adds a DAO layer and
some other stuff but it's basically Struts. New developers complained
because they couldn't use it on a resume. It's a shame sometimes what
people put in a name.
> Tapestry is so rich that, at first glance, Facelets does appear to
> steal some of its better ideas. However, once you use Tapestry a bit
> longer, you realize that the core strengths are not limited to the
> templates. The injection model in 4.0 (which could be "faked" in
> 3.0), the extensibility via HiveMind, the JavaScript generation, the
> localization support, and the whole approach at all levels to managing
> state .... these are very much part of Tapestry too, and harder to
> grasp immediately, and harder for JSF to replicate.
I know there's a ton of great stuff in Tapestry. This will become more
apparent as the documentation evolves for 4.0. I really like the
injection model. I have not grasped the benefits of tapestry's state
management. This is just because I don't fully understand it. I guess
keeping the least amount of information is HttpSession as possible is
good. But this can be accomplished through good coding practice. What
else?
Also, I think for me it's the little things, having a table component that
supports paging and sorting out of the box. JSF doesn't have. Plus,
DirectLink passing parameters directly to listener methods. JSF to my
knowledge only supports no arg listeners for CommandLinks (then you take
the data out of the request - ugly). And finally my favorite - being able
to return an actual java object representing the page to go to next! I
really like page injection.
Ryan
=======================================
Ryan Wynn
Websphere Portal Developer
IBM Business Consulting Services - Public Sector
Reston Office: 703-668-2478
Cell: 703-622-1977
rwynn@us.ibm.com
Howard Lewis Ship <hl...@gmail.com>
08/15/2005 02:49 PM
Please respond to
"Tapestry users"
To
Tapestry users <ta...@jakarta.apache.org>
cc
Subject
Re: Choosing Tapestry
On 8/15/05, Ryan Wynn <rw...@us.ibm.com> wrote:
> I have been using Tapestry 4.0 for 2 weeks now for portlet development
and
> I can say my experience has been very positive. I have found that my
> tapestry portlets have come out much much cleaner than their JSF
> counterparts.
Thanks! And thanks to McKesson Provider Technologies for funding this
aspect of Tapestry 4.0.
> I think the ability to inject pages and hivemend services
> really makes for an elegant design. Not only that but the line precise
> error reporting probably saved me hours of debugging (My mistakes in JSF
> JSPs get wrapped in very obscure ClassCastExceptions in the logs).
>
> However, I am tasked with choosing a framework for my client and
although
> Tapestry appeals to me it may not be right for this project. It seems
to
> me that with Facelets JSF is transforming more and more into Tapestry.
JSF
> tooling in WSAD (which is the project IDE) comes out of the box and is
> further along than Spindle in the portlet arena.
But how well does it work with Facelets? The tool integration is all
about the JSP view. Use a non-JSP view and most of the utility of the
tools dissappears.
> Also, the project uses
> applets quite extensively. From what I have read about Facelets I can
> leverage JSF outside of a web container with Swing or SWT.
Tapestry is so rich that, at first glance, Facelets does appear to
steal some of its better ideas. However, once you use Tapestry a bit
longer, you realize that the core strengths are not limited to the
templates. The injection model in 4.0 (which could be "faked" in
3.0), the extensibility via HiveMind, the JavaScript generation, the
localization support, and the whole approach at all levels to managing
state .... these are very much part of Tapestry too, and harder to
grasp immediately, and harder for JSF to replicate.
>
> Is there anything fundamentally stopping JSF (the "standard" + all that
> standard implies, e.g. it's not hard to hire a Struts expert) from
> stealing the best parts of Tapestry (line precise error/templating to
> start) and making me look like a fool for choosing Tapestry a couple
years
> from now?
Let's say everything you say might happen does come about. Well, then
your Tapestry skills will translate directly into JSF/Facelet skills,
and porting your application will be easy. Alternately, getting people
with JSF/Facelet skills will be easy, and they'll quickly adapt to the
"identical" Tapestry environment.
>
> Thanks,
> Ryan
>
> =======================================
> Ryan Wynn
> Websphere Portal Developer
> IBM Business Consulting Services - Public Sector
> Reston Office: 703-668-2478
> Cell: 703-622-1977
> rwynn@us.ibm.com
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Choosing Tapestry
Posted by Howard Lewis Ship <hl...@gmail.com>.
On 8/15/05, Ryan Wynn <rw...@us.ibm.com> wrote:
> I have been using Tapestry 4.0 for 2 weeks now for portlet development and
> I can say my experience has been very positive. I have found that my
> tapestry portlets have come out much much cleaner than their JSF
> counterparts.
Thanks! And thanks to McKesson Provider Technologies for funding this
aspect of Tapestry 4.0.
> I think the ability to inject pages and hivemend services
> really makes for an elegant design. Not only that but the line precise
> error reporting probably saved me hours of debugging (My mistakes in JSF
> JSPs get wrapped in very obscure ClassCastExceptions in the logs).
>
> However, I am tasked with choosing a framework for my client and although
> Tapestry appeals to me it may not be right for this project. It seems to
> me that with Facelets JSF is transforming more and more into Tapestry. JSF
> tooling in WSAD (which is the project IDE) comes out of the box and is
> further along than Spindle in the portlet arena.
But how well does it work with Facelets? The tool integration is all
about the JSP view. Use a non-JSP view and most of the utility of the
tools dissappears.
> Also, the project uses
> applets quite extensively. From what I have read about Facelets I can
> leverage JSF outside of a web container with Swing or SWT.
Tapestry is so rich that, at first glance, Facelets does appear to
steal some of its better ideas. However, once you use Tapestry a bit
longer, you realize that the core strengths are not limited to the
templates. The injection model in 4.0 (which could be "faked" in
3.0), the extensibility via HiveMind, the JavaScript generation, the
localization support, and the whole approach at all levels to managing
state .... these are very much part of Tapestry too, and harder to
grasp immediately, and harder for JSF to replicate.
>
> Is there anything fundamentally stopping JSF (the "standard" + all that
> standard implies, e.g. it's not hard to hire a Struts expert) from
> stealing the best parts of Tapestry (line precise error/templating to
> start) and making me look like a fool for choosing Tapestry a couple years
> from now?
Let's say everything you say might happen does come about. Well, then
your Tapestry skills will translate directly into JSF/Facelet skills,
and porting your application will be easy. Alternately, getting people
with JSF/Facelet skills will be easy, and they'll quickly adapt to the
"identical" Tapestry environment.
>
> Thanks,
> Ryan
>
> =======================================
> Ryan Wynn
> Websphere Portal Developer
> IBM Business Consulting Services - Public Sector
> Reston Office: 703-668-2478
> Cell: 703-622-1977
> rwynn@us.ibm.com
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org