Will back-compatibility hurt further T5 development?

[Vjeran Marcinko <vj...@email.t-com.hr>]

Hello all.

Although I am not a frequent poster, I still use Tapestry after I began
using it around 5 years ago. I was a bit suprised on amount of negative
publicity that the framework received after T5 was initated due to loss of
back-compatibility, but I could partly understand it if I imagine myself
working in a bigger, more inert company than mine. Back compatibility is
*the major* Howard's concern now as I can see it, but I would also like to
express my opinion that it can also hurt further improvement.

Version 5 is great, no doubt about it, but that doesn't mean it's perfect,
and it doesn't even mean that it's better in all aspects than older
versions. Howard brought a lot of inovative ideas here, so it would be a big
suprise if all of them were the best choice. I noticed that most talks about
further development of T5 is around area of documentation improvement (which
I can certainly agree with), or addition of further specifications like
Portlets or Spring Web Flow (which IMO is just potential burden in future),
like everything that is in place now is OK.

I am kind of guy that first tries to settle how basic web stuff works in any
web framework - such as application packaging, form editing, validation,
page navigation, CSS inclusion, dynamic image generation etc. Stuff that is
needed in every app. I don't care at first does it have some additional
modules around, such as Hibernate or Spring integration or similar since you
can always achieve these things easily if you fetch Servlet API underneath
it. Basic impression of any web framework comes from how well it does these
basic web stuff that I mentioned above.

T5 does not do all these basic stuff perfectly, but I am afraid that one can
wait a long time now for these to be changed since back compatibility is
such an issue now.

For example, I am not exactly happy with current packaging structure, since
it completely destroys domain-driven packaging. For example, I would like to
have some EditEmployeePage, ViewEmployee component, and maybe
EmployeeGridDataSource in one "employee" package, and now I have to have:
com.myapp.tapestry.pages.employee (for page)
com.myapp.tapestry.components.employee (for component)
com.myapp.tapestry.beans.employee (for EmployeeGridDataSource)
..and sometimes when I want to have utility class that accepts Tapestry
beans in :
com.myapp.tapestry.base
Classloader issues can be a lot of burden sometimes to overcome. Former
Tapestry versions did not have these. I understand that one gets fast
development due to reloading, but somehow this didn't impress me much. Maybe
its just me.

Anyway, in a light of back-compatibility-loss fear, I am afraid to think if
this packaging will ever be changed now since it looks like major
restructure of one of most improtant parts of Tapestry.

Passing of data between pages is also one of more basic stuff for me that I
look first to learn in any web framework. Current activation context is nice
idea, but IMO, it doesn't go all the way for every occasion. Jumpstart
examples clearly describe different situations and different needs. It would
be great to have some way to handle most of it. As I see it, named
parameters would probably do it. I have already seen requests for it on
these lists, but it isn't small/easy feature to add, so I am also sceptic 
that it would be implemented soon.

Even some smaller issues like this:
https://issues.apache.org/jira/browse/TAP5-182
made me think if back compatibility has become too much of a burden for the
framework.

Regards,
Vjeran


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

Re: Will back-compatibility hurt further T5 development?

[Angelo Chen <an...@yahoo.com.hk>]

I had a quite big t5 app in 5.0.18, when attempting to upgrade to 5.1, 
really got a problem, major ones are javascript inclusion, I decided to
rework that part in 5.0.18 first, after it's done, upgrading to 5.1 is
really just change a version number in the maven's pom, it's really very
easy, can't believe that.


Howard Lewis Ship wrote:
> 
> Actually, I think the jump from 5.0 to 5.1 included (behind the scenes)
> more
> significant changes than the ones you describe (except for package
> restructuring; that's sacrosanct and will not ever change).
> 
> I think the upgrade went easily for most users, but a few had stumbling
> blocks ... the deprecation of PrimaryKeyEncoder and replacement with
> ValueEncoder seemed to strike users unevenly.
> 
> In any case, I hope that future upgrades (5.1 to 5.2) will have more
> dramatic features and a smoother upgrade path.
> 
> 2009/6/20 Vjeran Marcinko <vj...@email.t-com.hr>
> 
>> Hello all.
>>
>> Although I am not a frequent poster, I still use Tapestry after I began
>> using it around 5 years ago. I was a bit suprised on amount of negative
>> publicity that the framework received after T5 was initated due to loss
>> of
>> back-compatibility, but I could partly understand it if I imagine myself
>> working in a bigger, more inert company than mine. Back compatibility is
>> *the major* Howard's concern now as I can see it, but I would also like
>> to
>> express my opinion that it can also hurt further improvement.
>>
>> Version 5 is great, no doubt about it, but that doesn't mean it's
>> perfect,
>> and it doesn't even mean that it's better in all aspects than older
>> versions. Howard brought a lot of inovative ideas here, so it would be a
>> big
>> suprise if all of them were the best choice. I noticed that most talks
>> about
>> further development of T5 is around area of documentation improvement
>> (which
>> I can certainly agree with), or addition of further specifications like
>> Portlets or Spring Web Flow (which IMO is just potential burden in
>> future),
>> like everything that is in place now is OK.
>>
>> I am kind of guy that first tries to settle how basic web stuff works in
>> any
>> web framework - such as application packaging, form editing, validation,
>> page navigation, CSS inclusion, dynamic image generation etc. Stuff that
>> is
>> needed in every app. I don't care at first does it have some additional
>> modules around, such as Hibernate or Spring integration or similar since
>> you
>> can always achieve these things easily if you fetch Servlet API
>> underneath
>> it. Basic impression of any web framework comes from how well it does
>> these
>> basic web stuff that I mentioned above.
>>
>> T5 does not do all these basic stuff perfectly, but I am afraid that one
>> can
>> wait a long time now for these to be changed since back compatibility is
>> such an issue now.
>>
>> For example, I am not exactly happy with current packaging structure,
>> since
>> it completely destroys domain-driven packaging. For example, I would like
>> to
>> have some EditEmployeePage, ViewEmployee component, and maybe
>> EmployeeGridDataSource in one "employee" package, and now I have to have:
>> com.myapp.tapestry.pages.employee (for page)
>> com.myapp.tapestry.components.employee (for component)
>> com.myapp.tapestry.beans.employee (for EmployeeGridDataSource)
>> ..and sometimes when I want to have utility class that accepts Tapestry
>> beans in :
>> com.myapp.tapestry.base
>> Classloader issues can be a lot of burden sometimes to overcome. Former
>> Tapestry versions did not have these. I understand that one gets fast
>> development due to reloading, but somehow this didn't impress me much.
>> Maybe
>> its just me.
>>
>> Anyway, in a light of back-compatibility-loss fear, I am afraid to think
>> if
>> this packaging will ever be changed now since it looks like major
>> restructure of one of most improtant parts of Tapestry.
>>
>> Passing of data between pages is also one of more basic stuff for me that
>> I
>> look first to learn in any web framework. Current activation context is
>> nice
>> idea, but IMO, it doesn't go all the way for every occasion. Jumpstart
>> examples clearly describe different situations and different needs. It
>> would
>> be great to have some way to handle most of it. As I see it, named
>> parameters would probably do it. I have already seen requests for it on
>> these lists, but it isn't small/easy feature to add, so I am also sceptic
>> that it would be implemented soon.
>>
>> Even some smaller issues like this:
>> https://issues.apache.org/jira/browse/TAP5-182
>> made me think if back compatibility has become too much of a burden for
>> the
>> framework.
>>
>> Regards,
>> Vjeran
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
> 
> 
> -- 
> Howard M. Lewis Ship
> 
> Creator of Apache Tapestry
> Director of Open Source Technology at Formos
> 
> 

-- 
View this message in context: http://www.nabble.com/Will-back-compatibility-hurt-further-T5-development--tp24126170p24130412.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


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

Re: Will back-compatibility hurt further T5 development?

[Howard Lewis Ship <hl...@gmail.com>]

Actually, I think the jump from 5.0 to 5.1 included (behind the scenes) more
significant changes than the ones you describe (except for package
restructuring; that's sacrosanct and will not ever change).

I think the upgrade went easily for most users, but a few had stumbling
blocks ... the deprecation of PrimaryKeyEncoder and replacement with
ValueEncoder seemed to strike users unevenly.

In any case, I hope that future upgrades (5.1 to 5.2) will have more
dramatic features and a smoother upgrade path.

2009/6/20 Vjeran Marcinko <vj...@email.t-com.hr>

> Hello all.
>
> Although I am not a frequent poster, I still use Tapestry after I began
> using it around 5 years ago. I was a bit suprised on amount of negative
> publicity that the framework received after T5 was initated due to loss of
> back-compatibility, but I could partly understand it if I imagine myself
> working in a bigger, more inert company than mine. Back compatibility is
> *the major* Howard's concern now as I can see it, but I would also like to
> express my opinion that it can also hurt further improvement.
>
> Version 5 is great, no doubt about it, but that doesn't mean it's perfect,
> and it doesn't even mean that it's better in all aspects than older
> versions. Howard brought a lot of inovative ideas here, so it would be a
> big
> suprise if all of them were the best choice. I noticed that most talks
> about
> further development of T5 is around area of documentation improvement
> (which
> I can certainly agree with), or addition of further specifications like
> Portlets or Spring Web Flow (which IMO is just potential burden in future),
> like everything that is in place now is OK.
>
> I am kind of guy that first tries to settle how basic web stuff works in
> any
> web framework - such as application packaging, form editing, validation,
> page navigation, CSS inclusion, dynamic image generation etc. Stuff that is
> needed in every app. I don't care at first does it have some additional
> modules around, such as Hibernate or Spring integration or similar since
> you
> can always achieve these things easily if you fetch Servlet API underneath
> it. Basic impression of any web framework comes from how well it does these
> basic web stuff that I mentioned above.
>
> T5 does not do all these basic stuff perfectly, but I am afraid that one
> can
> wait a long time now for these to be changed since back compatibility is
> such an issue now.
>
> For example, I am not exactly happy with current packaging structure, since
> it completely destroys domain-driven packaging. For example, I would like
> to
> have some EditEmployeePage, ViewEmployee component, and maybe
> EmployeeGridDataSource in one "employee" package, and now I have to have:
> com.myapp.tapestry.pages.employee (for page)
> com.myapp.tapestry.components.employee (for component)
> com.myapp.tapestry.beans.employee (for EmployeeGridDataSource)
> ..and sometimes when I want to have utility class that accepts Tapestry
> beans in :
> com.myapp.tapestry.base
> Classloader issues can be a lot of burden sometimes to overcome. Former
> Tapestry versions did not have these. I understand that one gets fast
> development due to reloading, but somehow this didn't impress me much.
> Maybe
> its just me.
>
> Anyway, in a light of back-compatibility-loss fear, I am afraid to think if
> this packaging will ever be changed now since it looks like major
> restructure of one of most improtant parts of Tapestry.
>
> Passing of data between pages is also one of more basic stuff for me that I
> look first to learn in any web framework. Current activation context is
> nice
> idea, but IMO, it doesn't go all the way for every occasion. Jumpstart
> examples clearly describe different situations and different needs. It
> would
> be great to have some way to handle most of it. As I see it, named
> parameters would probably do it. I have already seen requests for it on
> these lists, but it isn't small/easy feature to add, so I am also sceptic
> that it would be implemented soon.
>
> Even some smaller issues like this:
> https://issues.apache.org/jira/browse/TAP5-182
> made me think if back compatibility has become too much of a burden for the
> framework.
>
> Regards,
> Vjeran
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
Howard M. Lewis Ship

Creator of Apache Tapestry
Director of Open Source Technology at Formos