I think documentation will eventually address the OO 
issues (vs. scripting issues) that overwhelm new users.

BTW, the <property> tag is used to store meta data about 
pages, components, etc.  I think that's what you need.  
I use it in Vlib to mark pages as "admin", "normal" 
or "logged-in" (i.e., declartively controlling what you 
can and can't see).  The validate() method reads the 
property and may throw a PageRedirectException if the 
the user doesn't match the page.


--
[EMAIL PROTECTED]

http://tapestry.sf.net
> I didn't read my mail on this list for a minute so I missed the flame war...
> Here's my two cents.
> 
> Is Tapestry hard to learn?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
> YES. But all frameworks are hard to learn.
> 
> I spent a couple of weeks trying different frameworks. After reading
> up on a bunch, I gave both Barracuda and Tapestry a try. Barracuda had
> a longer learning curve, largely because it was not as easy to get up
> and running out of the box. It took me a week to figure out how to do
> what I needed to do with Tapestry, after that I could build my whole
> application very quickly. 
> 
> We had a PHP guy on staff at the time who learned JSP/Struts while here
> (JSP/Struts learning curve seemed to be on the order of months, not
> easy to pick up but now there are book I understand). After more than
> a month with Tapestry, he still didn't really get it. I take this as 
> evidence that it is hard to shift from a scripty type system to Tapestry,
> but JSP/Struts is no piece of cake either.
> 
> I think the solution is better documentation, and more importantly
> simpler examples - a cookbook type approach. This may be impossible
> given Tapestry's rate of development since new features are coming
> out so quickly. There's not a lot of motivation to write good 
> ducmentation when you know it has a shelf-life of minus five
> minutes (already obsolete by the time you write it).
> 
> Is Tapestry cumbersome once you've grokked it?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Sort of. IMO, Tapestry makes hard things easy and easy
> things hard. 
> 
> You get used to creating the .html, .page, and .java
> files but I find I'm often typing stuff that the framework could
> figure out for me. Something on the lines of anonymous components
> would be nice (for me). For instance, I don't think you
> should ever have to declare an Insert component - you should
> be able to specify a property-path in the <span> tag and
> just display the stuff. I agree with others that this opens
> up a Pandora's box which may lead to putting scripting in
> the HTML again. Maybe best to keep the lid on that - there's
> already a lot of players in that field.
> 
> The consensus on this list seems to be, Spindle is the solution
> to the drudgery aspect of Tapestry. 
> I'm not too comfortable with that line of thinking.
> Hiding a cumbersome development process behind great tools
> is more the Microsoft approach and it's expensive to maintain.
> If we're saying you need Spindle to make Tapestry usable, then
> we're saying you need to use Eclipse too. Switching IDEs is 
> a biggish investment for a developer to make. I've given Eclipse a 
> serious try (3 months) and IMO it's just not that great an IDE. 
> Also, Geoff has a hard time keeping up with new Tapestry versions
> and new Eclipse versions at the same time - he has a double coupling
> there which is not fun. I've never been able to use Spindle so far
> because either I needed features from a newer release of Tapestry
> than Spindle supported, or there were bugs in Spindle or Eclipse
> that prevented my use of it. Right now I can't even run Eclipse on
> my linux box because the 2.0 stream depends on a new version of
> the GTK and I need to install at least a dozen RPMS to solve that!
> 
> OTOH, I've found developing for Tapestry to be not _that_ painful 
> without Spindle. IDEs are starting to come out with good XML
> editors (the early access release of Intellij IDEA does, anyway).
> A DTD-aware XML editor makes developing for Tapestry _much_
> easier. Maybe Tapestry should try to optimize for this time of
> environment: java IDEs with good XML support. Then you don't
> need plugins for Eclipse, IDEA, JBuilder, Forte, NetBeans,
> (emacs!,) ...
> 
> <aside>
> Something that would be nice would be the capability to set
> some static parameters on your Page classes in the .jwc files.
> I basically have an EditProfilePage and a ListProfilesPage. These pages 
> need to be have a couple of things set on the - the EJB that
> they are using, the type of profile that they are managing. 
> For each .jwc I need to create a new subclass of one of
> these pages. All the subclass does is sets these two string
> parameters. I'd like to do that in the .jwc and not need the
> subclass. This would make for a more complex caching algorithm for
> the pages.
> </aside>
> 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer

Reply via email to