Wow! thanks to everyone! I think I won't need recursion in the model
(I hope so!), so I'll be doing some small app, if everything works
fine, I'll choose tapestry5 for this project. Thanks again

On Sun, Sep 11, 2011 at 2:01 PM, Muhammad Gelbana <m.gelb...@gmail.com> wrote:
> I'm still not thorough with tapestry but I really love it. I think I
> reached the point when you say "I get it now". In the past the docs
> weren't clear enough for a beginner like me and I didn't actually
> grasp the idea of tml files integration with java classes. But now I
> do.
>
> Now the docs are FAR much better and very helpful. Although I think
> they need a very simple push to be 100% useful for beginners and
> professionals. Yet I don't find documentation for Javascript as good
> as the docs for server-side tapestry (I mean docs about the Tapestry
> namespace specially to tweak ajax calls for example). You won't
> usually need it but in some cases you will. And then you will have to
> send your question to the list...unless google suffices :)
>
> Components are inreasing, including 3rd party components and there are
> plenty already.
>
> Taha has a VERY resourceful blog about tapestry: http://tawus.wordpress.com/
> Geoff Callender is doing a marvelous job explaining tapestry by
> example: http://jumpstart.doublenegative.com.au/home.html
>
> And there are many others..google won't let you down
>
> Just give your self some time to understand how it works...and you will love 
> it.
>
> Tapestry...satisfaction guaranteed :D
>
> On Sun, Sep 11, 2011 at 5:48 PM, Wechsung, Wulf <wulf.wechs...@sap.com> wrote:
>> Yeah, disregard my former mail, please. I'm completely wrong on that 
>> component stuff as Josh pointed out.
>> My confusion stems from how loops and components interact. Try this:
>>
>> Component class:
>>
>> public class Counter {
>>
>>    private int counter = 0;
>>
>>    public int getCounter() {
>>        counter++;
>>        return counter;
>>    }
>> }
>>
>> Component template:
>> ${counter}
>>
>> Page template:
>>
>> <t:loop source="1..5">
>>        <t:counter />
>> </t:loop>
>>
>>        <t:counter />
>>        <t:counter />
>>        <t:counter />
>>
>> With t5.2.6 this results in: 1 2 3 4 5 1 1 1
>>
>> Apparently, I only use loops so I incorrectly inferred general component 
>> behavior when the reason for that behavior is that within the loop it's only 
>> one instance of the component.
>>
>> My apologies!
>>
>> Kind Regards,
>> Wulf
>>
>>
>> -----Original Message-----
>> From: Wechsung, Wulf [mailto:wulf.wechs...@sap.com]
>> Sent: Sonntag, 11. September 2011 17:18
>> To: Tapestry users
>> Subject: RE: tapestry ready for production?
>>
>>
>>
>>> and nothing prevents you from having the same component multiple times on 
>>> the same page
>>
>> Well, it can be rendered multiple times but the java object that is the 
>> component only exists once which means that any state isn't a parameter 
>> value is not contained in an instance of a component (as people could 
>> reasonably expect) but must be manually restored in setupRender etc. I'm not 
>> making a value judgment, I'm just stating that one should be aware of this.
>>
>>> In my opinion, Tapestry does an awesome job of abstracting away the 
>>> request/response cycle
>>
>> It's a lot better than doing servlets, that's for sure. Again, expectations 
>> matter. For example, I was very confused that if I have a component in a 
>> loop that takes the iteration variable as parameter, this parameter will be 
>> null if I trigger an action event that results in a partial page request.
>>
>>
>>
>>
>> -----Original Message-----
>> From: Bob Harner [mailto:bobhar...@gmail.com]
>> Sent: Sonntag, 11. September 2011 16:29
>> To: Tapestry users
>> Subject: Re: tapestry ready for production?
>>
>> On Sun, Sep 11, 2011 at 9:25 AM, Wechsung, Wulf <wulf.wechs...@sap.com> 
>> wrote:
>>> Hello Alfonso,
>>>
>>> Disclaimer: I'm not very familiar with struts and faces because I refuse to 
>>> use anything that relies on XML for more than initial configuration.
>>>
>>> So, t5. I will focus on things that I personally find less than ideal. I 
>>> don't do this because I dislike tapestry ( I like it!) but I think for 
>>> someone deciding on a framework it's important to know the full story.
>>>
>>> A lot of people will say that it's a component-oriented framework which is 
>>> of course correct. However, tapestry has a very specific idea about what a 
>>> component is and how they should behave.
>>>
>>> For one, components are basically singletons so you can never have the same 
>>> component twice on the page. You can have it render twice with different 
>>> parameters which can accomplish the same thing but makes it necessary to 
>>> careful manage the components state.
>>
>> Actually, while components are indeed implemented as singletons (with
>> their state coming from a per-thread map) in 5.2 and later, this is an
>> internal implementation detail of Tapestry, and nothing prevents you
>> from having the same component multiple times on the same page. I'm
>> really puzzled by this statement.
>>
>>>
>>> T5 Components also do not abstract away the request / response / request 
>>> cycle that is the bane of all web-developers. So, again, careful state 
>>> management is necessary especially in cases where you have form-containing 
>>> components in a loop.
>>
>> In my opinion, Tapestry does an awesome job of abstracting away the
>> request/response cycle -- much better than any action-based framework.
>> With sensible use of contexts and ValueEncoders, developers can really
>> focus on manipulating objects rather than the encoding-to-text and
>> decoding-to-objects process with each request. There are of course
>> some sensible compromises so that Tapestry apps can remain lean and
>> fast (e.g. avoiding storing everything in the HTTP session like JSF
>> apps usually do).
>>
>>>
>>> These things are not showstoppers by any means but until one has completely 
>>> absorbed the t5 component model it can be painful to work with it. That of 
>>> course is not a fault in tapestry's fault, it just a thing to look out for.
>>>
>>>
>>> What I do think is a real problem is the lack of recursion in components. 
>>> It's not possible to have a component contain itself even indirectly. There 
>>> are workarounds for specific cases (I think t5.3 contains a dynamic tree 
>>> component) but if you plan on doing anything that would require full 
>>> component recursion you should consider carefully if you want to go ahead 
>>> with using tapestry.
>>>
>>>
>>> Now, don't misunderstand, I still think that tapestry is great, especially 
>>> how easy ajax becomes. I also think that the framework itself is very 
>>> stable and contains very few errors and runs quite fast. So, if you can 
>>> work with the component model, yes, tapestry is absolutely ready for 
>>> production.
>>>
>>> Kind Regards,
>>> Wulf
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Alfonso Quiroga [mailto:alfonsose...@gmail.com]
>>> Sent: Sonntag, 11. September 2011 10:56
>>> To: Tapestry users
>>> Subject: tapestry ready for production?
>>>
>>> Hi! I've used tapestry 5.0 some time ago, in a small app at home. Now
>>> in my work I've to decide which framework we will use for a state
>>> application on internet.
>>> I've a lot of experience with struts2, I can just choose that, but I
>>> prefer the component model against the action model.
>>>
>>> 1) Is tapestry 5.3 a good choice for a site, where 2 o 3 web
>>> developers will be developing?
>>>
>>> 2) I'm NOT an expert in tapestry, and I know the "static structure, dynamic
>>> behavior" has some limits, which are this limits?
>>>
>>> 3) Finally, in the future, in my job I will need some widgets that
>>> could use ajax, is hard to accomplish this? (in struts2 is really easy)
>>>
>>> Thanks in advance,
>>>
>>> Alfonso
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
>
>
> --
> Regards,
> Muhammad Gelbana
> Java Developer
>
> ---------------------------------------------------------------------
> 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