> Please give us some examples of hard-to-build modules.
Distributed configuration is great for something simple, but to use it for 
something more involved can be tricky, for example Tapestry IoC provides the 
platform for developing IoC services, but doesn't follow through with web 
services integration. Restful web services are easy but for a complete web 
services stack (METRO, CXF etc...) you need much more plumbing. This type of 
integration comes out of the box in Spring and grails... there are few docs on 
this type of thing, so basically the route we are advised to take is to join 
the two contexts, but this is hardly the Tapestry way.

Peter

-- 
If you are not an intended recipient of this e-mail, please notify the sender, 
delete it and do not read, act upon, print, disclose, copy, retain or 
redistribute it. Please visit http://www.albourne.com/email.html for important 
additional terms relating to this e-mail.

----- Original Message -----
From: "Thiago H. de Paula Figueiredo" <thiag...@gmail.com>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Wednesday, 23 December, 2009 13:47:54 GMT +02:00 Athens, Beirut, 
Bucharest, Istanbul
Subject: Re: Discussion

Em Wed, 23 Dec 2009 09:20:05 -0200, Piero Sartini <li...@pierosartini.de>  
escreveu:

> I never liked Spring because of its XML configuration.

There's also JavaConfig and use of annotations instead of XML, but  
Tapestry-IoC still looks better to me. And Spring doesn't have distributed  
configuration.

> I like guice and tapestry-ioc better.

Guice inspired Tapestry-IoC. :)

What I meant is that it is hard to find your
> way around the IoC concepts neccessary to master tapestry..

What concepts exactly?

> Some people say it is over engineered - I don't think so. But maybe
> its exposing too much of its excellence to the user, forcing us to be
> as excellent as the developers.

Please give us some examples.

> Which brings me to another point: It
> is hard to contribute to tapestry, because you need a very high
> skillset to join the effort. It's _way_ easier to contribute to wicket
> or struts2. Result is, of course, that their codebase is not nearly as
> good as tapestry's.

You can also contribute by writing libraries. ;)

> That may be one point. But our module landscape outside the core is
> really thin. And it is also hard to build some modules, because it
> would not be the tapestry way.

Please give us some examples of hard-to-build modules.

> Think about jQuery or other JS
> libraries (ExtJS, Dojo, etc) for example (IMHO the Prototype
> dependency frightened a lot of people).

This point was discussed a lot and
I have a component that uses a very nice jQuery color picker and it works.

> If you remember some weeks back, I was trying to integrate YAML (Yet
> another Multicolumn Layout: http://www.yaml.de) with tapestry... I
> gave up.

 From a quick read (I'm busy writing a Tapestry course now), it seems that  
YAML is a CSS framework.
The thread is here:  
http://old.nabble.com/Customize-markup-of-client-side-validation-to26668520s302.html#a26668520
There was a solution proposed (your own ValidationDecorator). Have you had  
problems with this approach?

> Maybe because of lacking tapestry documentation.. but it is
> really not as easy as it should be! Tapestry claims to be flexible..
> but adopting it to your needs is difficult (and not documented).

The documentation has been improved by Howard and you can see its progress  
here: http://tapestry.formos.com/nightly/tapestry5/

>> The day you understand distributed configuration I guess you'll change  
>> your mind. :)
>
> Guice does have all of this as well

Guice has distributed configuration, but not explicitly and not as easy as  
in Tapestry-IoC.

> (and comes with warp-persist,
> offering JPA and db4o integrations - transactions as well).

In this case, it seems to me it's a matter of money. Many people at Google  
work on it in their paid time, while almost everyone working on Tapestry  
work in their free time.

> See above for two modules I tried to build with tapestry-ioc.

I'm sorry, but your examples weren't enough for me to understand.
One counter-example: in my Ars Machina Project, I have authentication and  
authorization packages. I only need to add annotations to my page classes  
to inform if it needs a logged user and/or what roles the need use to be  
able to use that page. I have an access logger package that works just by  
adding it to the classpath.

> What I would love to be better documented is how to adopt the markup
> to your needs. Changing CSS is easy - but I did not find out how to
> change the markup yet.

The markup is responsibility of each component. You can write a mixin to  
change the generated markup or write your own components.

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da  
Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to