subject:"Re\: Discussion"

I didn't use one, but I believe such service exists that resolves client
timezone by client IP.
Client IP - Location - TimeZone. And this all may be resolved in very
first request.

On Thu, Aug 19, 2010 at 10:43, Fernando Padilla f...@alum.mit.edu wrote:

  Since our apps deals with sports team schedules, timezones are important
 for us.  That's why I kept trying to suggest timezone support, whenever you
 discussed locale support.

 But your main question is how to determine a client's timezone.  There is
 no http-header way to get it, and a Javascript timezone detector is the only
 thing I could come up with.  Even with Javascript timezone detection, you
 will not know a user's timezone on their first request, only after the
 timezone detector executes, calls back to the server, and a user's
 httpsession has been updated with their timezone.

 Even if after you're OK with that, Javascript only gives you access to an
 offset for a particular date, but not the actual timezone Id.  To get the
 timezone Id you have to take some offset samples for a few dates, and back
 track those samples against the timezone database in Java.

 What I did, was to take a few date samples ( jan, jun, today, two weeks
 from today ), and generate the offsets for those dates on the client-side,
 then compare those values against all known timezones on the server-side.
  That will give you a short list of possible timezones that will all work
 for the user.  Then I just store that against the user (httpSesstion), much
 as you would store the user's Locale - through putting timezoneid in url is
 not an option.

 If you're interested, what's the best way to give you the few files that
 would get you started?  attach to a bug?


 - TimeZoneLookup.java
   - service, does the timezone database lookup, versus date offset samples
 - components/common/TimeZoneDetector.java
 - components/common/TimeZoneDetector.js
   - component that executes javascript to get date offset samples, and
 calls back to server for capturing
   - doesn't render if timezone has been detected already
   - we have our layout include timezone detector, so all pages include it
 - pages/common/TimeZoneDetector.java
   - javascript calls back independent page (not component action)
   - because i don't want to deal with unnecessary page activation of pages
 containing the Detector




 On 8/7/10 9:10 AM, Howard Lewis Ship wrote:

 This is something that's been nagging me. Although there's a bunch of good
 options for selecting a date (or date/time) as JavaScript components bult
 into Tapestry, or available elsewhere ... none of them address the issue
 of
 the client and the server operating in different time zones.

 At the very least, these components probably should include a time zone
 drop
 down list (or other means of selection).

 I haven't been able to find a sure-fire way of determing the user's time
 zone from the HttpRequest.

 I'm curious what kinds of solutions the community have used to address
 this
 issue. It would be nice to come up with a true solution for Tapestry 5.3.

 One option is a bit of JavaScript that reports the client's time zone (or
 just time) to the server so that the server can identify their time zone
 automatically.


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




-- 
Dmitry Gusev

AnjLab Team
http://anjlab.com

Re: DISCUSSION: Time zones and date selection

In addition to my previous message:

http://stackoverflow.com/questions/41504/timezone-lookup-from-latitude-longitude

I will probably use this approach to determine initial client timezone since
I'm already use URL/IP to location functionality there:
http://github.com/dmitrygusev/ping-service/blob/master/ping-service/src/dmitrygusev/ping/services/IPUtils.java

(FYI this class uses http://ip-whois.net to resolve locations.)

In current implementation I'm using UTC time by default in ping-service
(GAE's default timezone), but user may specify its timezone in profile.

On Thu, Aug 19, 2010 at 12:36, Dmitry Gusev dmitry.gu...@gmail.com wrote:

I didn't use one, but I believe such service exists that resolves client
timezone by client IP.
Client IP - Location - TimeZone. And this all may be resolved in very
first request.

On Thu, Aug 19, 2010 at 10:43, Fernando Padilla f...@alum.mit.edu wrote:

Since our apps deals with sports team schedules, timezones are important
for us. That's why I kept trying to suggest timezone support, whenever you
discussed locale support.

But your main question is how to determine a client's timezone. There is
no http-header way to get it, and a Javascript timezone detector is the only
thing I could come up with. Even with Javascript timezone detection, you
will not know a user's timezone on their first request, only after the
timezone detector executes, calls back to the server, and a user's
httpsession has been updated with their timezone.

Even if after you're OK with that, Javascript only gives you access to an
offset for a particular date, but not the actual timezone Id. To get the
timezone Id you have to take some offset samples for a few dates, and back
track those samples against the timezone database in Java.

What I did, was to take a few date samples ( jan, jun, today, two weeks
from today ), and generate the offsets for those dates on the client-side,
then compare those values against all known timezones on the server-side.
That will give you a short list of possible timezones that will all work
for the user. Then I just store that against the user (httpSesstion), much
as you would store the user's Locale - through putting timezoneid in url is
not an option.

If you're interested, what's the best way to give you the few files that
would get you started? attach to a bug?

- TimeZoneLookup.java
- service, does the timezone database lookup, versus date offset samples
- components/common/TimeZoneDetector.java
- components/common/TimeZoneDetector.js
- component that executes javascript to get date offset samples, and
calls back to server for capturing
- doesn't render if timezone has been detected already
- we have our layout include timezone detector, so all pages include it
- pages/common/TimeZoneDetector.java
- javascript calls back independent page (not component action)
- because i don't want to deal with unnecessary page activation of pages
containing the Detector

On 8/7/10 9:10 AM, Howard Lewis Ship wrote:

This is something that's been nagging me. Although there's a bunch of
good
options for selecting a date (or date/time) as JavaScript components bult
into Tapestry, or available elsewhere ... none of them address the issue
of
the client and the server operating in different time zones.

At the very least, these components probably should include a time zone
drop
down list (or other means of selection).

I haven't been able to find a sure-fire way of determing the user's time
zone from the HttpRequest.

I'm curious what kinds of solutions the community have used to address
this
issue. It would be nice to come up with a true solution for Tapestry 5.3.

One option is a bit of JavaScript that reports the client's time zone (or
just time) to the server so that the server can identify their time zone
automatically.

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

--
Dmitry Gusev

AnjLab Team
http://anjlab.com

--
Dmitry Gusev

AnjLab Team
http://anjlab.com

Re: DISCUSSION: Time zones and date selection

Here's the service description:
http://www.geonames.org/export/web-services.html#timezone

http://www.geonames.org/export/web-services.html#timezoneAnd JSON example
for ping-service (XML is service also there):

http://ws.geonames.org/timezoneJSON?lat=37.41lng=-122.05

{time:2010-08-19 01:56,countryName:United
States,sunset:2010-08-19
19:55,rawOffset:-8,dstOffset:-7,countryCode:US,gmtOffset:-8,lng:-122.05,sunrise:2010-08-19
06:27,timezoneId:America/Los_Angeles,lat:37.41}

On Thu, Aug 19, 2010 at 12:49, Dmitry Gusev dmitry.gu...@gmail.com wrote:

 In addition to my previous message:


 http://stackoverflow.com/questions/41504/timezone-lookup-from-latitude-longitude

 I will probably use this approach to determine initial client timezone
 since I'm already use URL/IP to location functionality there:

 http://github.com/dmitrygusev/ping-service/blob/master/ping-service/src/dmitrygusev/ping/services/IPUtils.java

 (FYI this class uses http://ip-whois.net to resolve locations.)

 In current implementation I'm using UTC time by default in ping-service
 (GAE's default timezone), but user may specify its timezone in profile.

 On Thu, Aug 19, 2010 at 12:36, Dmitry Gusev dmitry.gu...@gmail.comwrote:

 I didn't use one, but I believe such service exists that resolves client
 timezone by client IP.
 Client IP - Location - TimeZone. And this all may be resolved in very
 first request.


 On Thu, Aug 19, 2010 at 10:43, Fernando Padilla f...@alum.mit.eduwrote:

  Since our apps deals with sports team schedules, timezones are important
 for us.  That's why I kept trying to suggest timezone support, whenever you
 discussed locale support.

 But your main question is how to determine a client's timezone.  There is
 no http-header way to get it, and a Javascript timezone detector is the only
 thing I could come up with.  Even with Javascript timezone detection, you
 will not know a user's timezone on their first request, only after the
 timezone detector executes, calls back to the server, and a user's
 httpsession has been updated with their timezone.

 Even if after you're OK with that, Javascript only gives you access to an
 offset for a particular date, but not the actual timezone Id.  To get the
 timezone Id you have to take some offset samples for a few dates, and back
 track those samples against the timezone database in Java.

 What I did, was to take a few date samples ( jan, jun, today, two weeks
 from today ), and generate the offsets for those dates on the client-side,
 then compare those values against all known timezones on the server-side.
  That will give you a short list of possible timezones that will all work
 for the user.  Then I just store that against the user (httpSesstion), much
 as you would store the user's Locale - through putting timezoneid in url is
 not an option.

 If you're interested, what's the best way to give you the few files that
 would get you started?  attach to a bug?


 - TimeZoneLookup.java
   - service, does the timezone database lookup, versus date offset
 samples
 - components/common/TimeZoneDetector.java
 - components/common/TimeZoneDetector.js
   - component that executes javascript to get date offset samples, and
 calls back to server for capturing
   - doesn't render if timezone has been detected already
   - we have our layout include timezone detector, so all pages include it
 - pages/common/TimeZoneDetector.java
   - javascript calls back independent page (not component action)
   - because i don't want to deal with unnecessary page activation of
 pages containing the Detector




 On 8/7/10 9:10 AM, Howard Lewis Ship wrote:

 This is something that's been nagging me. Although there's a bunch of
 good
 options for selecting a date (or date/time) as JavaScript components
 bult
 into Tapestry, or available elsewhere ... none of them address the issue
 of
 the client and the server operating in different time zones.

 At the very least, these components probably should include a time zone
 drop
 down list (or other means of selection).

 I haven't been able to find a sure-fire way of determing the user's time
 zone from the HttpRequest.

 I'm curious what kinds of solutions the community have used to address
 this
 issue. It would be nice to come up with a true solution for Tapestry
 5.3.

 One option is a bit of JavaScript that reports the client's time zone
 (or
 just time) to the server so that the server can identify their time zone
 automatically.


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




 --
 Dmitry Gusev

 AnjLab Team
 http://anjlab.com




 --
 Dmitry Gusev

 AnjLab Team
 http://anjlab.com




-- 
Dmitry Gusev

AnjLab Team
http://anjlab.com

Re: DISCUSSION: Time zones and date selection

2010-08-19 Thread Fernando Padilla

 Yeah, i guess each his own.  Though the ip resolution way does seem 
cleaner in some ways, it does seem way more complicated in others.. 
and dependent on other services.. etc..


I guess we just realized that TimeZone Detector should be easily 
pluggable, to fit people's taste and requirements... :)


On 8/19/10 1:36 AM, Dmitry Gusev wrote:

I didn't use one, but I believe such service exists that resolves client
timezone by client IP.
Client IP -  Location -  TimeZone. And this all may be resolved in very
first request.

On Thu, Aug 19, 2010 at 10:43, Fernando Padillaf...@alum.mit.edu  wrote:


  Since our apps deals with sports team schedules, timezones are important
for us.  That's why I kept trying to suggest timezone support, whenever you
discussed locale support.

But your main question is how to determine a client's timezone.  There is
no http-header way to get it, and a Javascript timezone detector is the only
thing I could come up with.  Even with Javascript timezone detection, you
will not know a user's timezone on their first request, only after the
timezone detector executes, calls back to the server, and a user's
httpsession has been updated with their timezone.

Even if after you're OK with that, Javascript only gives you access to an
offset for a particular date, but not the actual timezone Id.  To get the
timezone Id you have to take some offset samples for a few dates, and back
track those samples against the timezone database in Java.

What I did, was to take a few date samples ( jan, jun, today, two weeks
from today ), and generate the offsets for those dates on the client-side,
then compare those values against all known timezones on the server-side.
  That will give you a short list of possible timezones that will all work
for the user.  Then I just store that against the user (httpSesstion), much
as you would store the user's Locale - through putting timezoneid in url is
not an option.

If you're interested, what's the best way to give you the few files that
would get you started?  attach to a bug?


- TimeZoneLookup.java
   - service, does the timezone database lookup, versus date offset samples
- components/common/TimeZoneDetector.java
- components/common/TimeZoneDetector.js
   - component that executes javascript to get date offset samples, and
calls back to server for capturing
   - doesn't render if timezone has been detected already
   - we have our layout include timezone detector, so all pages include it
- pages/common/TimeZoneDetector.java
   - javascript calls back independent page (not component action)
   - because i don't want to deal with unnecessary page activation of pages
containing the Detector




On 8/7/10 9:10 AM, Howard Lewis Ship wrote:


This is something that's been nagging me. Although there's a bunch of good
options for selecting a date (or date/time) as JavaScript components bult
into Tapestry, or available elsewhere ... none of them address the issue
of
the client and the server operating in different time zones.

At the very least, these components probably should include a time zone
drop
down list (or other means of selection).

I haven't been able to find a sure-fire way of determing the user's time
zone from the HttpRequest.

I'm curious what kinds of solutions the community have used to address
this
issue. It would be nice to come up with a true solution for Tapestry 5.3.

One option is a bit of JavaScript that reports the client's time zone (or
just time) to the server so that the server can identify their time zone
automatically.



-
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

Re: DISCUSSION: Time zones and date selection

One more thing, I've added Geonames to ping service to measure its
performance and got the following statistics:

Was made 47 requests (one for every 15 minutes) with average response time
750 ms.
During this period I got some bad responses:

{status:{message:the hourly limit of 3000 credits for the IP address
72.14.192.68 has been exceeded. Please throttle your requests or use the
commercial service.,value:19}}
Its availability percent (percent of expected responses) was 93.75% for the
past 12 hours.
So its probably not a good option to use Geonames in a cloud for free... but
still an option.

On Thu, Aug 19, 2010 at 19:56, Fernando Padilla f...@alum.mit.edu wrote:

  Yeah, i guess each his own.  Though the ip resolution way does seem
 cleaner in some ways, it does seem way more complicated in others.. and
 dependent on other services.. etc..

 I guess we just realized that TimeZone Detector should be easily pluggable,
 to fit people's taste and requirements... :)


 On 8/19/10 1:36 AM, Dmitry Gusev wrote:

 I didn't use one, but I believe such service exists that resolves client
 timezone by client IP.
 Client IP -  Location -  TimeZone. And this all may be resolved in very
 first request.

 On Thu, Aug 19, 2010 at 10:43, Fernando Padillaf...@alum.mit.edu
  wrote:

   Since our apps deals with sports team schedules, timezones are important
 for us.  That's why I kept trying to suggest timezone support, whenever
 you
 discussed locale support.

 But your main question is how to determine a client's timezone.  There is
 no http-header way to get it, and a Javascript timezone detector is the
 only
 thing I could come up with.  Even with Javascript timezone detection, you
 will not know a user's timezone on their first request, only after the
 timezone detector executes, calls back to the server, and a user's
 httpsession has been updated with their timezone.

 Even if after you're OK with that, Javascript only gives you access to an
 offset for a particular date, but not the actual timezone Id.  To get the
 timezone Id you have to take some offset samples for a few dates, and
 back
 track those samples against the timezone database in Java.

 What I did, was to take a few date samples ( jan, jun, today, two weeks
 from today ), and generate the offsets for those dates on the
 client-side,
 then compare those values against all known timezones on the server-side.
  That will give you a short list of possible timezones that will all work
 for the user.  Then I just store that against the user (httpSesstion),
 much
 as you would store the user's Locale - through putting timezoneid in url
 is
 not an option.

 If you're interested, what's the best way to give you the few files that
 would get you started?  attach to a bug?


 - TimeZoneLookup.java
   - service, does the timezone database lookup, versus date offset
 samples
 - components/common/TimeZoneDetector.java
 - components/common/TimeZoneDetector.js
   - component that executes javascript to get date offset samples, and
 calls back to server for capturing
   - doesn't render if timezone has been detected already
   - we have our layout include timezone detector, so all pages include it
 - pages/common/TimeZoneDetector.java
   - javascript calls back independent page (not component action)
   - because i don't want to deal with unnecessary page activation of
 pages
 containing the Detector




 On 8/7/10 9:10 AM, Howard Lewis Ship wrote:

  This is something that's been nagging me. Although there's a bunch of
 good
 options for selecting a date (or date/time) as JavaScript components
 bult
 into Tapestry, or available elsewhere ... none of them address the issue
 of
 the client and the server operating in different time zones.

 At the very least, these components probably should include a time zone
 drop
 down list (or other means of selection).

 I haven't been able to find a sure-fire way of determing the user's time
 zone from the HttpRequest.

 I'm curious what kinds of solutions the community have used to address
 this
 issue. It would be nice to come up with a true solution for Tapestry
 5.3.

 One option is a bit of JavaScript that reports the client's time zone
 (or
 just time) to the server so that the server can identify their time zone
 automatically.


  -
 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




-- 
Dmitry Gusev

AnjLab Team
http://anjlab.com

Re: DISCUSSION: Time zones and date selection

2010-08-08 Thread Joost Schouten (mailing lists)

Hi,

I do everything server side with the help of a custom
TimeZoneAwareDatePicker wrapping your tapx datepicker. It takes a
source (I store everything in UTC) and display timezone (the users
timezone) to do the conversion. This suits me because I will almost
always know my users timezone as they need to be logged in.

In all my applications where I need to be timezone aware, I make sure
to have my users specify it upfront and store it all server side. To
help my users I assume the most logical tz through some util classes I
build around http://icu-project.org/apiref/icu4j/. These util classes
have methods like getBestMatchingTimeZone(Locale locale).

Personally I wouldn't want to add a time zone drop down to a date
picker as it would be too much in my opinion.

Cheers,
Joost

On Sat, Aug 7, 2010 at 6:10 PM, Howard Lewis Ship hls...@gmail.com wrote:
 This is something that's been nagging me. Although there's a bunch of good
 options for selecting a date (or date/time) as JavaScript components bult
 into Tapestry, or available elsewhere ... none of them address the issue of
 the client and the server operating in different time zones.

 At the very least, these components probably should include a time zone drop
 down list (or other means of selection).

 I haven't been able to find a sure-fire way of determing the user's time
 zone from the HttpRequest.

 I'm curious what kinds of solutions the community have used to address this
 issue. It would be nice to come up with a true solution for Tapestry 5.3.

 One option is a bit of JavaScript that reports the client's time zone (or
 just time) to the server so that the server can identify their time zone
 automatically.

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to learn
 how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com


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

Re: DISCUSSION: Time zones and date selection

2010-08-07 Thread Christophe Cordenier

Hi

Just an add, related issue was reported there
https://issues.apache.org/jira/browse/TAP5-841


2010/8/7 Howard Lewis Ship hls...@gmail.com

 This is something that's been nagging me. Although there's a bunch of good
 options for selecting a date (or date/time) as JavaScript components bult
 into Tapestry, or available elsewhere ... none of them address the issue of
 the client and the server operating in different time zones.

 At the very least, these components probably should include a time zone
 drop
 down list (or other means of selection).

 I haven't been able to find a sure-fire way of determing the user's time
 zone from the HttpRequest.

 I'm curious what kinds of solutions the community have used to address this
 issue. It would be nice to come up with a true solution for Tapestry 5.3.

 One option is a bit of JavaScript that reports the client's time zone (or
 just time) to the server so that the server can identify their time zone
 automatically.

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn
 how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com




-- 
Regards,
Christophe Cordenier.

Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com

Re: Discussion

2009-12-26 Thread Thiago H. de Paula Figueiredo

Em Thu, 24 Dec 2009 10:31:15 -0200, Alessandro Bottoni  
alexbott...@gmail.com escreveu:



Regarding this topics, let me remind the ML people that there are at
least two projects that tries to supply Tapestry 5 with the remaining
components needed to build a full-stack framework (or something like
that): Tynamo (formerly known as Trails) and AppFuse. T5 can be a
simple framework but Tynamo and AppFuse are much more than this.


I guess you can add the Ars Machina Project there, although the approach  
is different (several focused packages vs one single framework) and I  
didn't have time to write the documentation yet. I'm already using them in  
my projects: If you're adventurous enough, take a look at the sources:  
http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/ :) Warning: the  
newer code of most projects are in branches, not the trunk.



I think that what the newbie (like me) and the end-user/dev are
expecting from T5+Tynamo is something like a Drupal on steroids: a
empty CMS (coming from a Maven archetype) that can be easily configured


I beg to differ. A web framework has a very different objective from a  
CMS. You can build a CMS with Tapestry, but T5, AFAIK, never had the goal  
of being one.


--
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

Re: Discussion

2009-12-26 Thread Alessandro Bottoni

Il 26/12/2009 19:24, Thiago H. de Paula Figueiredo ha scritto:
 I think that what the newbie (like me) and the end-user/dev are
 expecting from T5+Tynamo is something like a Drupal on steroids: a
 empty CMS (coming from a Maven archetype) that can be easily configured
 
 I beg to differ. A web framework has a very different objective from a
 CMS. You can build a CMS with Tapestry, but T5, AFAIK, never had the
 goal of being one.


Yes, of course. I said T5+Tynamo just to underline this detail. T5 alone
cannot play this role. T5+Tynamo, on the other side, do have to offer
this level of readiness.

Thinking at T5 (alone) as the underlining technology of Tynamo (or of a
general purpose CMS) can make easier to spot what is missing and what is
wrong. After all, what the poor developer will have to build is
something very similar to Tynamo (or to Drupal).

CU
-- 

Alessandro Bottoni
Website: http://www.alessandrobottoni.it/

When future stopped to be a promise and started to be a threat?
-- Street wall graffiti, Bologna, 1999


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

Re: Discussion

2009-12-24 Thread Alessandro Bottoni

Il 23/12/2009 19:48, Thiago H. de Paula Figueiredo ha scritto:
 Em Wed, 23 Dec 2009 16:22:49 -0200, Piero Sartini 
 I don't like it as well - but tapestry should provide an alternative.
 Maybe the question is if tapestry wants to be a full-stack framework
 or just deliver some building blocks. For being a full-stack
 framework, there is not enough functionality available. To just
 provide building blocks, it dictates too much (javascript library,
 markup, and so on). Of course this is just my feeling.
 
 I cannot speak for the project, but I think Tapestry tries to be a Web
 framework, not a full stack. At least not yet. ;)

Regarding this topics, let me remind the ML people that there are at
least two projects that tries to supply Tapestry 5 with the remaining
components needed to build a full-stack framework (or something like
that): Tynamo (formerly known as Trails) and AppFuse. T5 can be a
simple framework but Tynamo and AppFuse are much more than this.
Looking at T5 from this perspective, it looks very good.

T5 should/could supply us with just the fundamental blocks and
Tynamo/AppFuse could/should do the rest. Also, it should be much easier
to manage the whole dev process in this way.

I think that what the newbie (like me) and the end-user/dev are
expecting from T5+Tynamo is something like a Drupal on steroids: a
empty CMS (coming from a Maven archetype) that can be easily configured
(like Drupal) and extended (Drupal is a pain to modify and extend, when
used for big and complex projects). In other words, a empty system than
can be used as a good starting point for a real-world (that is: quite
complex) web application.

Such a Maven archetype should supply all of the basic building blocks of
a real-world application:
- access control (Acegi/Spring security or something like that)
- i18n/i10n and language switching
- persistance (against MySQL, for example)
- user registration
- user administration
- captcha?
- e-mail verification (send/verify)
- etc.

To the end-user should remain the responsability to de/activate every
single feature and to configure them.

Such a system, being based on a well-engineered technology like T5,
would be immensely easier to extend and modify than CMSs like Drupal and
immensely more robust.

As long as I can see, T5 and Tynamo are already evolving together in
this way. It is just a matter of time to have such a Drupal-on-steroids
archetype.

As Piero said, at the moment T5 is probably enforcing some choice that
could/should be left to the end-user/dev (javascript library, markup,
etc.) but, as long as I can see, it should not be very hard to loosen
such requisites in future releases. Dojo and JQuery can already be used
together with T5 (cannot they?) and allowing the dev to use a different
mark-up should be just a matter to accept a different XML namespace (a
superset of the T5's). Am I wrong?

JM2C
-- 

Alessandro Bottoni
Website: http://www.alessandrobottoni.it/

Perfection is finally attained not when there is no longer anything to
add but when there is no longer anything to take away.
 -- Antoine de Saint-Exupéry


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

Re: Discussion

2009-12-24 Thread Wilson Ikeda

Alfonso Quiroga wrote:

³Last, it would be good more components (ui components).²

+1 , plus it really would be nice if it comes before the above
javascript/prototype/jquery implementation/change:

³There's a plan not to switch from Prototype to jQuery. There's a plan to
have JavaScript stacks, one implemented with Prototype, another with
jQuery. No dates yet.²

How much javascript are the developers here using? I prefer to use only when
necessary (yeah, I¹m one that runs from it like from the devil :-))

Merry Christmas to everyone on the list.

Re: Discussion

2009-12-23 Thread Lutz Hühnken

Hi everybody,

I think the discussion on TheServerSide actually is somewhat
interesting, but not because of the unfortunate Tapestry vs. Wicket
flame war. Let's have a look at the topic leading to that...

- One part of Java EE 6 is CDI (JSR 299)  -
http://jcp.org/en/jsr/detail?id=299 - originally called Web beans. I
think it was inspired by Gavin Kings Seam Framework.

- The reference implementation for that seems to be something called
Weld - http://docs.jboss.org/weld/reference/1.0.0/en-US/html/

- Weld has Wicket support build in, and the examples are given in
Wicket (although the Java EE standard would be JSF 2) because Wicket
is easier to learn than JSF (at least Gavin King says so in
http://in.relation.to/Bloggers/HowToStartLearningJavaEE6, but I think
many would agree with that).

So the interesting (to me, at least) questions are:

- How does CDI relate to Tapesty and Tapestry IOC?

- Should / could Tapestry incorporate / conform to CDI somehow?

- Should we try to add Tapestry support to Weld?

- Or is Java EE 6 / CDI just not relevant to Tapestry?

I haven't really looked at Web Beans resp. CDI yet, but from first
site, it defines some context scopes (request, session, application,
conversation) and some annotation based dependency injection.
Both areas are already covered by Tapestry (although afaik there is no
conversation scope (yet) in Tapestry).

So are CDI and Tapestry mutually exclusive? Or should Tapestry be
refactored to use standard CDI annotations, so it can claim to be a
CDI / JSR 299 implementation?

I would love to hear your opinions about that.

Regards,
Lutz




-- 
altocon GmbH
http://www.altocon.de/
Software Development, Consulting
Hamburg, Germany

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

Re: Discussion

Em Wed, 23 Dec 2009 06:25:14 -0200, Lutz Hühnken  
lh.tapestry.l...@googlemail.com escreveu:



Hi everybody,


Hi!


So the interesting (to me, at least) questions are:
- How does CDI relate to Tapesty and Tapestry IOC?
- Should / could Tapestry incorporate / conform to CDI somehow?
- Should we try to add Tapestry support to Weld?
- Or is Java EE 6 / CDI just not relevant to Tapestry?


There's a recent discussion about that in the dev mailing list. Everyone  
is invited. :)


--
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

Re: Discussion

2009-12-23 Thread Gerald Bauer

Lutz,

Having seen some discussions in the past about the history of Tapestry, I'm
wondering what the status of Tapestry with CDI support will be. In other
words, is it again going to result a new major release incompatible with
previous versions? I think CDI in it's current form, if should be supported,
would require some fundamental changes to the core of Tapestry's IoC that
would definitely result in API break. At least the Spring guys also say so
about their framework.

I have an idea, may be a controversial one. I've seen much about Tapestry
and think it's a nice Framework. But what I still don't understand is why
it's not widely in use. It existed before Wicket but Wicket is far more
popular. I don't think it's only because it's users are very vocal. There is
also a saying that a good product sometimes sells itself.
My proposition is why not let Tapestry and Wicket join hands, migrate some
of the nice ideas to Wicket and lets try to go standardize Wicket as a JSR.

Again, I know this is a controversial proposition that might result in some
immature ones labeling and calling me names, as I've seen in the archives.
On the other hand I know there are wise and intelligent ones in this
community who would offer constructive arguments. It is these group of
people that I'll consider serious.

Gerald

2009/12/23 Lutz Hühnken lh.tapestry.l...@googlemail.com

 Hi everybody,

 I think the discussion on TheServerSide actually is somewhat
 interesting, but not because of the unfortunate Tapestry vs. Wicket
 flame war. Let's have a look at the topic leading to that...

 - One part of Java EE 6 is CDI (JSR 299)  -
 http://jcp.org/en/jsr/detail?id=299 - originally called Web beans. I
 think it was inspired by Gavin Kings Seam Framework.

 - The reference implementation for that seems to be something called
 Weld - http://docs.jboss.org/weld/reference/1.0.0/en-US/html/

 - Weld has Wicket support build in, and the examples are given in
 Wicket (although the Java EE standard would be JSF 2) because Wicket
 is easier to learn than JSF (at least Gavin King says so in
 http://in.relation.to/Bloggers/HowToStartLearningJavaEE6, but I think
 many would agree with that).

 So the interesting (to me, at least) questions are:

 - How does CDI relate to Tapesty and Tapestry IOC?

 - Should / could Tapestry incorporate / conform to CDI somehow?

 - Should we try to add Tapestry support to Weld?

 - Or is Java EE 6 / CDI just not relevant to Tapestry?

 I haven't really looked at Web Beans resp. CDI yet, but from first
 site, it defines some context scopes (request, session, application,
 conversation) and some annotation based dependency injection.
 Both areas are already covered by Tapestry (although afaik there is no
 conversation scope (yet) in Tapestry).

 So are CDI and Tapestry mutually exclusive? Or should Tapestry be
 refactored to use standard CDI annotations, so it can claim to be a
 CDI / JSR 299 implementation?

 I would love to hear your opinions about that.

 Regards,
 Lutz




 --
 altocon GmbH
 http://www.altocon.de/
 Software Development, Consulting
 Hamburg, Germany

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

Re: Discussion

2009-12-23 Thread Peter Stavrinides

 There's a recent discussion about that in the dev mailing list. Everyone  
 is invited. :)
Thiago could you provide a link perhaps?

-- 
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: Gerald Bauer gtat...@gmail.com
To: Tapestry users users@tapestry.apache.org
Sent: Wednesday, 23 December, 2009 11:59:47 GMT +02:00 Athens, Beirut, 
Bucharest, Istanbul
Subject: Re: Discussion

Lutz,

Having seen some discussions in the past about the history of Tapestry, I'm
wondering what the status of Tapestry with CDI support will be. In other
words, is it again going to result a new major release incompatible with
previous versions? I think CDI in it's current form, if should be supported,
would require some fundamental changes to the core of Tapestry's IoC that
would definitely result in API break. At least the Spring guys also say so
about their framework.

I have an idea, may be a controversial one. I've seen much about Tapestry
and think it's a nice Framework. But what I still don't understand is why
it's not widely in use. It existed before Wicket but Wicket is far more
popular. I don't think it's only because it's users are very vocal. There is
also a saying that a good product sometimes sells itself.
My proposition is why not let Tapestry and Wicket join hands, migrate some
of the nice ideas to Wicket and lets try to go standardize Wicket as a JSR.

Again, I know this is a controversial proposition that might result in some
immature ones labeling and calling me names, as I've seen in the archives.
On the other hand I know there are wise and intelligent ones in this
community who would offer constructive arguments. It is these group of
people that I'll consider serious.

Gerald

2009/12/23 Lutz Hühnken lh.tapestry.l...@googlemail.com

 Hi everybody,

 I think the discussion on TheServerSide actually is somewhat
 interesting, but not because of the unfortunate Tapestry vs. Wicket
 flame war. Let's have a look at the topic leading to that...

 - One part of Java EE 6 is CDI (JSR 299)  -
 http://jcp.org/en/jsr/detail?id=299 - originally called Web beans. I
 think it was inspired by Gavin Kings Seam Framework.

 - The reference implementation for that seems to be something called
 Weld - http://docs.jboss.org/weld/reference/1.0.0/en-US/html/

 - Weld has Wicket support build in, and the examples are given in
 Wicket (although the Java EE standard would be JSF 2) because Wicket
 is easier to learn than JSF (at least Gavin King says so in
 http://in.relation.to/Bloggers/HowToStartLearningJavaEE6, but I think
 many would agree with that).

 So the interesting (to me, at least) questions are:

 - How does CDI relate to Tapesty and Tapestry IOC?

 - Should / could Tapestry incorporate / conform to CDI somehow?

 - Should we try to add Tapestry support to Weld?

 - Or is Java EE 6 / CDI just not relevant to Tapestry?

 I haven't really looked at Web Beans resp. CDI yet, but from first
 site, it defines some context scopes (request, session, application,
 conversation) and some annotation based dependency injection.
 Both areas are already covered by Tapestry (although afaik there is no
 conversation scope (yet) in Tapestry).

 So are CDI and Tapestry mutually exclusive? Or should Tapestry be
 refactored to use standard CDI annotations, so it can claim to be a
 CDI / JSR 299 implementation?

 I would love to hear your opinions about that.

 Regards,
 Lutz




 --
 altocon GmbH
 http://www.altocon.de/
 Software Development, Consulting
 Hamburg, Germany

 -
 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

Re: Discussion

Em Wed, 23 Dec 2009 07:59:47 -0200, Gerald Bauer gtat...@gmail.com  
escreveu:



Lutz,


Hi!

Having seen some discussions in the past about the history of Tapestry,  
I'm  wondering what the status of Tapestry with CDI support will be. In  
other

words, is it again going to result a new major release incompatible with
previous versions? I think CDI in it's current form, if should be  
supported,

would require some fundamental changes to the core of Tapestry's IoC that
would definitely result in API break. At least the Spring guys also say  
so about their framework.


Tapestry-IoC's public API is very, very small, so I don't think an API  
break is necessary at all for CDI support.

My classes are Tapestry-IoC services and they have no dependency on it.
AFAIK, all it needs to implement CDI is to keep the current semantics and  
change to CDI's when CDI's @Inject annotation is found.


My proposition is why not let Tapestry and Wicket join hands, migrate  
some of the nice ideas to Wicket and lets try to go standardize Wicket  
as a JSR.


That wouldn't work. Wicket and Tapestry share many concepts, but the  
approach to implement them is radically different. I don't think another  
JSR concerning web frameworks would be accepted. I also think that JSRs  
work better for lower level issues (transaction management,  
object-relational mapping). Anyway, I love the idea of competition: we  
have many different Web frameworks with many different approaches, with  
many of them bringing some nice inovations that can be added to the  
others. Diversity is a very good thing. :)


By the way, why don't we standardize Tapestry instead of Wicket? ;)

Again, I know this is a controversial proposition that might result in  
some immature ones labeling and calling me names, as I've seen in the  
archives.


We had some unbelievably annoying trolls in the past, almost all of them  
Wicket users, so there was a precedent here. If you're not a troll,  
welcome to the list. :)


--
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

Re: Discussion

Em Wed, 23 Dec 2009 08:21:23 -0200, Peter Stavrinides  
p.stavrini...@albourne.com escreveu:



There's a recent discussion about that in the dev mailing list. Everyone
is invited. :)

Thiago could you provide a link perhaps?


Yes! :)  
http://old.nabble.com/JSR-229%2C-JSR-330-and-other-integrations-to26857781.html


--
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

Re: Discussion

 Having seen some discussions in the past about the history of Tapestry, I'm
 wondering what the status of Tapestry with CDI support will be. In other
 words, is it again going to result a new major release incompatible with
 previous versions? I think CDI in it's current form, if should be supported,
 would require some fundamental changes to the core of Tapestry's IoC that
 would definitely result in API break. At least the Spring guys also say so
 about their framework.

I am not sure if it is possible or not to integrate CDI without
breaking backwards
compatibility... but it is something we should find out. Spring guys
are no reliable
source, they want to sell their product and if I were them, I would
fear CDI as well.

 I have an idea, may be a controversial one. I've seen much about Tapestry
 and think it's a nice Framework. But what I still don't understand is why
 it's not widely in use. It existed before Wicket but Wicket is far more
 popular. I don't think it's only because it's users are very vocal. There is
 also a saying that a good product sometimes sells itself.

I've also thought about this, and my only conclusion is that Tapestry is too
difficult to master. Especially when it comes to tapestry-ioc and
getting productive
with it.

I am not talking about building the frontend and components.. this is
easy and IMHO
the thing where tapestry really shines.

But there are way too less integrations - see my tapestry-jpa experiment for an
example. It works, but it would need some love from some smarter people than me
to get proper unit tests and some missing parts.

If I look at Wicket or other frameworks there are lots and lots of
integration modules
for just everything. Why is that? My answer is because it is way
easier to write them.

 My proposition is why not let Tapestry and Wicket join hands, migrate some
 of the nice ideas to Wicket and lets try to go standardize Wicket as a JSR.

I am not sure I would like this. I've tried wicket in the past, and
for me it is too verbose.
I don't like the Swing-Approach and these inner classes everywhere.
Tapestry's approach
to the front-end programming is excellent, I don't want to trade this.

But I would be perfectly fine trading the IoC container...

 Piero

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

Re: Discussion

2009-12-23 Thread Peter Stavrinides



-- 
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.

 I've also thought about this, and my only conclusion is that Tapestry is too
 difficult to master. Especially when it comes to tapestry-ioc and
 getting productive
 with it.
Only because of the lack of good docs and tutorials... its a pity though 
because it may appear daunting to begin with, but when you do learn it, it is 
so simple its sick.  

regards,
Peter


- Original Message -
From: Piero Sartini li...@pierosartini.de
To: Tapestry users users@tapestry.apache.org
Sent: Wednesday, 23 December, 2009 12:28:35 GMT +02:00 Athens, Beirut, 
Bucharest, Istanbul
Subject: Re: Discussion

 Having seen some discussions in the past about the history of Tapestry, I'm
 wondering what the status of Tapestry with CDI support will be. In other
 words, is it again going to result a new major release incompatible with
 previous versions? I think CDI in it's current form, if should be supported,
 would require some fundamental changes to the core of Tapestry's IoC that
 would definitely result in API break. At least the Spring guys also say so
 about their framework.

I am not sure if it is possible or not to integrate CDI without
breaking backwards
compatibility... but it is something we should find out. Spring guys
are no reliable
source, they want to sell their product and if I were them, I would
fear CDI as well.

 I have an idea, may be a controversial one. I've seen much about Tapestry
 and think it's a nice Framework. But what I still don't understand is why
 it's not widely in use. It existed before Wicket but Wicket is far more
 popular. I don't think it's only because it's users are very vocal. There is
 also a saying that a good product sometimes sells itself.

I've also thought about this, and my only conclusion is that Tapestry is too
difficult to master. Especially when it comes to tapestry-ioc and
getting productive
with it.

I am not talking about building the frontend and components.. this is
easy and IMHO
the thing where tapestry really shines.

But there are way too less integrations - see my tapestry-jpa experiment for an
example. It works, but it would need some love from some smarter people than me
to get proper unit tests and some missing parts.

If I look at Wicket or other frameworks there are lots and lots of
integration modules
for just everything. Why is that? My answer is because it is way
easier to write them.

 My proposition is why not let Tapestry and Wicket join hands, migrate some
 of the nice ideas to Wicket and lets try to go standardize Wicket as a JSR.

I am not sure I would like this. I've tried wicket in the past, and
for me it is too verbose.
I don't like the Swing-Approach and these inner classes everywhere.
Tapestry's approach
to the front-end programming is excellent, I don't want to trade this.

But I would be perfectly fine trading the IoC container...

 Piero

-
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

Re: Discussion

Em Wed, 23 Dec 2009 08:28:35 -0200, Piero Sartini li...@pierosartini.de  
escreveu:



I am not sure if it is possible or not to integrate CDI without
breaking backwards
compatibility... but it is something we should find out.


Agreed. :)

I've also thought about this, and my only conclusion is that Tapestry is  
too difficult to master. Especially when it comes to tapestry-ioc and

getting productive with it.


What exactly is difficult to master? I think Tapestry-IoC is easier to  
learn than Spring.
Maybe there's a sensation of Tapestry being hard to master because it's  
built on IoC and has many hooks to do many things. Other frameworks has  
many hooks, but less ways to customize them without changing the sources  
or doing difficult configurations.



If I look at Wicket or other frameworks there are lots and lots of
integration modules
for just everything. Why is that? My answer is because it is way
easier to write them.


I guess is that because these frameworks are older and people had more  
time to write these integration modules. Tapestry 5 is way younger,  
specially when you think that the first stable version was released in  
December 18th, 2009, one year and 5 days ago. Wicket 1.0 was released in  
June 2005, 4.5 years ago. That's a 3.5 years head start.


There isn't an integration with JFreeChart or JasperReports, for example,  
maybe because it's so easy to write it (a page returning StreamResponse in  
its onActivate() method).



But I would be perfectly fine trading the IoC container...


The day you understand distributed configuration I guess you'll change  
your mind. :)


I also use Spring, and I think Tapestry-IoC is bothe easier and more  
powerful.


But what exactly do you find difficult in Tapestry-IoC? What could be  
easier? What could be better documented? What have you tried to do with  
T-IoC and failed?
Feedback is very important and we can use it to improve Tapestry and  
Tapestry-IoC. ;)


--
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

Re: Discussion

 I've also thought about this, and my only conclusion is that Tapestry is
 too difficult to master. Especially when it comes to tapestry-ioc and
 getting productive with it.

 What exactly is difficult to master? I think Tapestry-IoC is easier to learn
 than Spring.
 Maybe there's a sensation of Tapestry being hard to master because it's
 built on IoC and has many hooks to do many things. Other frameworks has many
 hooks, but less ways to customize them without changing the sources or doing
 difficult configurations.

I never liked Spring because of its XML configuration. I like guice
and tapestry-ioc better. What I meant is that it is hard to find your
way around the IoC concepts neccessary to master tapestry.. I am
learning something new every day, and do develop with tapestry 5 for
about one year now.

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. 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.

 If I look at Wicket or other frameworks there are lots and lots of
 integration modules
 for just everything. Why is that? My answer is because it is way
 easier to write them.

 I guess is that because these frameworks are older and people had more time
 to write these integration modules. Tapestry 5 is way younger, specially
 when you think that the first stable version was released in December 18th,
 2009, one year and 5 days ago. Wicket 1.0 was released in June 2005, 4.5
 years ago. That's a 3.5 years head start.

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. Think about jQuery or other JS
libraries (ExtJS, Dojo, etc) for example (IMHO the Prototype
dependency frightened a lot of people).

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. 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).

 There isn't an integration with JFreeChart or JasperReports, for example,
 maybe because it's so easy to write it (a page returning StreamResponse in
 its onActivate() method).

I agree :)

 But I would be perfectly fine trading the IoC container...

 The day you understand distributed configuration I guess you'll change your
 mind. :)

Guice does have all of this as well (and comes with warp-persist,
offering JPA and db4o integrations - transactions as well).
By the way, look out for google sitebricks... it reminds me a lot of tapestry.

 I also use Spring, and I think Tapestry-IoC is bothe easier and more
 powerful.

See below, I don't even tried to use Spring starting with EJB3
there was no need to do so.

 But what exactly do you find difficult in Tapestry-IoC? What could be
 easier? What could be better documented? What have you tried to do with
 T-IoC and failed?
 Feedback is very important and we can use it to improve Tapestry and
 Tapestry-IoC. ;)

See above for two modules I tried to build with tapestry-ioc. My
conclusion is that integrating third-party modules is too difficult.
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.

  Piero

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

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

Re: Discussion

2009-12-23 Thread P . Stavrinides

 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

Re: Discussion

2009-12-23 Thread Alessandro Bottoni

Il 23/12/2009 11:28, Piero Sartini ha scritto:
 I have an idea, may be a controversial one. I've seen much about Tapestry
 and think it's a nice Framework. But what I still don't understand is why
 it's not widely in use. It existed before Wicket but Wicket is far more
 popular. I don't think it's only because it's users are very vocal. There is
 also a saying that a good product sometimes sells itself.
 
 I've also thought about this, and my only conclusion is that Tapestry is too
 difficult to master. Especially when it comes to tapestry-ioc and
 getting productive
 with it.

As a newbie, I have to say that learning Tapestry (5) is actually a
little bit more complicated than what you could expect after having read
the available marketing documentation. Maybe this (apparently steep)
learning curve has kept the masses of developers/users away from Tapestry.

Nevertheless, this apparent difficulty is in large part just a matter of
documentation and/or examples. From this point of view, Wicket seems to
be much more appetizing. Just have a look at these pages:

http://wicketstuff.org/wicket13/
http://sourceforge.net/projects/wicket-stuff/files/

It is not surprising that many developers could prefer a framework that
supply them with a lot of working, ready-to-use components and/or a lot
of code examples.

BEWARE: I'm not saying that Wicket /is/ better or more complete than
Tapestry. I'm just saying that Wicket is /presented/ (or /offered/) to
the public in a better way.

I think that it is possible to fill this gap, for example using Tynamo
and AppFuse as examples/codebases. At the end, it is just a matter of
documentation and support.

 I am not talking about building the frontend and components.. this is
 easy and IMHO
 the thing where tapestry really shines.

I agree. Tapestry is much more elegant than many other frameworks from
this point of view. This part of Tapestry should not be under discussion.

I do not know if the IoC container is the real and sole source of the
scarce appreciation of Tapestry (if even exists such a scarce
appreciation) but... see below.

 But there are way too less integrations - see my tapestry-jpa experiment for 
 an
 example. It works, but it would need some love from some smarter people than 
 me
 to get proper unit tests and some missing parts.
 
 If I look at Wicket or other frameworks there are lots and lots of
 integration modules
 for just everything. Why is that? My answer is because it is way
 easier to write them.

I'm afraid you are right: /this/ seems to be the main, real weak point
of Tapestry. I do not know Tapestry well enough to have a solid opinion
about this topic but it seems to me quite evident that writing an
integration module is somehow (much?) more difficult than it should be.

Unfortunately, this can be a heavy limit for Tapestry. A real webapp
very often uses many external modules and the simple fact of not having
a easy way to write and/or integrate them can be a good reason for
abandoning this framework.

I came from the Python world and, as you probably know, a large part of
the success of Python is related to the easyness of integrating existing
C and C++ library with the Python interpreter (using SIP or SWIG). It
seems to me a lesson to learn.

I wonder: is it possible to improve the existing integration mechanism
of Tapestry (that is: the existing IoC container)? How? Or should we
replace it with a different/new one? Which one?

JM2C

-- 

Alessandro Bottoni
Website: http://www.alessandrobottoni.it/

Who wants to remember that escape-x-alt-control-left shift-b puts you
into super-edit-debug-compile mode?
 -- (Discussion in comp.os.linux.misc on the intuitiveness of
commands, especially Emacs.)


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

Re: Discussion


Em Wed, 23 Dec 2009 10:13:59 -0200, p.stavrini...@albourne.com escreveu:


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.


I wasn't clear: when I'm comparing Tapestry-IoC with Spring, I'm actually  
comparing it to Spring-Core itself, not to the whole Spring ecosystem.
There's no doubt that Tapestry-IoC lacks some integration with other  
packages when compared to other IoC frameworks.


--
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

Re: Discussion

Em Wed, 23 Dec 2009 10:14:53 -0200, Alessandro Bottoni  
alexbott...@gmail.com escreveu:



As a newbie, I have to say that learning Tapestry (5) is actually a
little bit more complicated than what you could expect after having read
the available marketing documentation.


This is a known issue.


Maybe this (apparently steep)
learning curve has kept the masses of developers/users away from  
Tapestry.


You can use Tapestry almost without using Tapestry-IoC, so I don't thin


BEWARE: I'm not saying that Wicket /is/ better or more complete than
Tapestry. I'm just saying that Wicket is /presented/ (or /offered/) to
the public in a better way.


I think you're probably right.


I do not know if the IoC container is the real and sole source of the
scarce appreciation of Tapestry (if even exists such a scarce
appreciation) but... see below.


I don't think so.


I'm afraid you are right: /this/ seems to be the main, real weak point
of Tapestry. I do not know Tapestry well enough to have a solid opinion
about this topic but it seems to me quite evident that writing an
integration module is somehow (much?) more difficult than it should be.


I think you're looking for the cause in the wrong places. I guess these  
integratiosn weren't written just because, unfortunately, Tapestry is not  
very well-known, so few people use it and write extensions and  
integrations. Or Tapestry users didn't have the need to write them. The  
recentness of Tapestry doesn't help either.


Take a look at the t5-restful-webservices project written by Bill  
Holloway:  
http://code.google.com/p/t5-restful-webservices/wiki/GettingStarted. It  
implements JSR 311: JAX-RS: The JavaTM API for RESTful Web Services for  
Tapestry. Take a look at the sources. Just three classes, none of them  
large. Spring integration has a small number of lines of code. 11 kb  
total. There's integration with Tapestry Spring Security. It isn't hard,  
people haven't had the time or need to write them.



I wonder: is it possible to improve the existing integration mechanism
of Tapestry (that is: the existing IoC container)? How?


It would be better to discuss actual integration problems and them attack  
them. If anyone has already had them, please post they here.



Or should we replace it with a different/new one? Which one?


I don't see any reason at all to replace it. If it has shortcomings, let's  
fix them! :)


--
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

Re: Discussion

Em Wed, 23 Dec 2009 11:20:41 -0200, Piero Sartini li...@pierosartini.de  
escreveu:



What concepts exactly?


Starting in the frontend, there are concepts like the static
structure, dynamic behaviour, the Environment and the Assets which are
hard to get. Thats what I remind of fighting with some months ago.
Also the lag of some functionality: select models out of beans (there
is a wiki entry, why not include it into core?!), file system assets,
etc.


There are all Tapestry issues, not Tapestry-IoC ones. I was discussing  
Tapestry-IoC.
Static structure, dynamic behaviour won't change because it's Tapestry's  
architecture. It allows faster execution and no need to put render state  
into the session, allowing way less memory consumption. Its documentation  
can be improved, of course. The same can be said about Environment (just a  
stack of values) and Assets.


Select models out of beans could be improved. My Tapestry CRUD package has  
a solution for that.



in 5.2 I am currenty fighting how to white list my resources... some
default examples to allow pictures, css, etc would be nice. (has been
some time I looked, maybe its now there).


You're talking about a snapshot. This behaviour was changed and now  
everything in the context is allowed.



In the backend, it gets more complicated: contributing services,
decorating services, overriding services...


I don't think they're complicated. The hard part is to find what to  
contribute, decorate or override. But now we're diving inside Tapestry's  
architecture, that is made of many small services to be easy to override.  
The documentation can be improved about it.



You should know I've tried ;-) BTW the libraries are spread all over
the web (google code, kenai, github, tap360..).


There are links to them in http://tapestry.apache.org/.


tapestry-cdi, tapestry-jpa2, tapestry-persistence in general (with
transactions ;).


CDI and JPA were released few weeks ago and they were mostly written to be  
used inside an EJB container. Implementing CDI is not a piece of cake.



Also, the available examples are hard to understand..
take tapestry-spring. It's poorly commented/documented and IMHO hard
to understand what is going on. Sure, its very little code - but maybe
that is why it is so hard :)


All it does is to provide Spring beans as Tapestry services. :)


I know - but the component library uses prototype, and its not
documented that integrating jquery is easy. There is no jquery module,
etc.


There's not much need for a module. Just add $jQuery.noConflict(); and  
properly-written jQuery plugins work.



Yes.. I had, but will try again the next days. The point is: A custom
ValidationDecorator is not documented anywhere. Also it seems a bit
overcomplicated to just implement some custom markup.


You're changing the output generated by some. Try to do the same in  
another framework. ;) The documentation could mention it, of course.



Good to hear! One wish: Could you explain RegexAuthorizer and
WhitelistAuthorizer in more detail, maybe with some common examples?


This will be done soon, I guess.


Very good example: Security is another thing I had expected to just
work out of the box in a web framework like tapestry. It does not, and
is not that easy for a new user to come up with a solution (and to
understand the concepts behind the explanations in the wiki).


There are many ways of modeling and implementing authentication and  
authorization, so I think it's not a Tapestry responsibility. Of course,  
we could have some integration with OpenID, OAuth and some security  
implementation.



Another argument: If it is that easy to build modules, where is the
transaction module you want that badly?


1) I'm not paid to work on Tapestry. I wish I was, and I wish this badly.  
I didn't have time to write them as I'm and independent developer and I  
was trying to make my ends meet. All my time is devoted now to projects  
that can help me earn some cash. (By the way, if anyone wants to hire  
someone with Tapestry and Hibernate experience to implement something, I'm  
here! :)


2) Now we've hit a Tapestry-IoC deficiency: annotations put in service  
implementations aren't available in the service proxies. Again, I didn't  
have time to fix this.


3) Implementing transaction management isn't so easy, specially when you  
want to support pseudo-nested transactions.



Or.. maybe tapestry-ioc gets in your way somehow?


In this specific scenario, #2 above gets in my way. I've never hit another  
issue with Tapestry-IoC, and I built many packages on the top of it. You  
can see for yourself here:  
http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/



Maybe its hard to integrate
with tapestry-hibernate ... or maybe its hard to come up with a
solution that will be useable by other persistence modules as well.
However, it seems to be not that easy :)


Besides the proxy issue, you're wrong: it wouldn't be difficult to  
integrate with

Re: Discussion

2009-12-23 Thread Alessandro Bottoni

Il 23/12/2009 13:45, Thiago H. de Paula Figueiredo ha scritto:
 I think you're looking for the cause in the wrong places. I guess these
 integratiosn weren't written just because, unfortunately, Tapestry is
 not very well-known, so few people use it and write extensions and
 integrations. 

Hence, the relatively scarce fame of Tapestry can be considered a
problem in itself. If few people know Tapestry and few people write few
code and support it, then the whole framework became less palatable.
Maybe, we should do something about it...

For what regards me, I still hope to be able to write some
docu/article/marketing stuff in the near future (with the help of the
members of this list, of course). Let's hope this helps.

 I wonder: is it possible to improve the existing integration mechanism
 of Tapestry (that is: the existing IoC container)? How?
 
 It would be better to discuss actual integration problems and them
 attack them. If anyone has already had them, please post they here.
 
 Or should we replace it with a different/new one? Which one?
 
 I don't see any reason at all to replace it. If it has shortcomings,
 let's fix them! :)

Well, I'm not sure that the T5 IoC container is completely innocent. It
is true that T5 IoC is much lighter and much more manageable than the
Spring's one. It is also true that its mechanism of configuration is
very elegant.

Nevertheless, I wonder if its original architecture represents a barrier
for the programmers used to Spring IoC or other containers.

Maybe it is just a matter of pre-existing skills and programming habits.
Maybe a compatibility layer could help (for example: accepting both
the T5 and the Spring configuration sintax).

Or, maybe, it is a subtle matter of compatibility between the T5 IoC
container and the modules we try to integrate (given that most of them
were designed to work with other types of IoC containers).

I wonder, for example, if there is some Spring IoC (or other IoC
container) feature that is missing in the T5 IoC and that can make any
difference. Could it be a (maybe obscure) missing feature the reason why
a few programmers find so hard to develop a module integration library?

Anyway, these are JM2C.

-- 

Alessandro Bottoni
Website: http://www.alessandrobottoni.it/

Hofstadter's Law: It always takes longer than you expect, even when you
take into account Hofstadter's Law.
— Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid


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

Re: Discussion

Em Wed, 23 Dec 2009 12:07:21 -0200, Alessandro Bottoni  
alexbott...@gmail.com escreveu:



Hence, the relatively scarce fame of Tapestry can be considered a
problem in itself. If few people know Tapestry and few people write few
code and support it, then the whole framework became less palatable.
Maybe, we should do something about it...


You've hit the head of the nail. ;)


For what regards me, I still hope to be able to write some
docu/article/marketing stuff in the near future (with the help of the
members of this list, of course). Let's hope this helps.


It surely helps.


Well, I'm not sure that the T5 IoC container is completely innocent. It
is true that T5 IoC is much lighter and much more manageable than the
Spring's one. It is also true that its mechanism of configuration is
very elegant.


:)


Nevertheless, I wonder if its original architecture represents a barrier
for the programmers used to Spring IoC or other containers.


It will be a barrier for anyone used to another IoC container. The  
architecture of IoC containers, AFAIK, is very similar to each other. You  
have beans/services, dependency injection, AOP, no much beyond that.



Maybe it is just a matter of pre-existing skills and programming habits.


I don't know if this is an issue, but it is for almost anything in  
software development. That's exactly why I think many people still use  
Struts when there are many better alternatives. Inertia.



Maybe a compatibility layer could help (for example: accepting both
the T5 and the Spring configuration sintax).


This could be added to the Spring integration, except the XML part, that  
is awful.



Or, maybe, it is a subtle matter of compatibility between the T5 IoC
container and the modules we try to integrate (given that most of them
were designed to work with other types of IoC containers).


The Spring integration does that. We could also do similar integrations  
with EJB3, Weld (for CDI), etc.



I wonder, for example, if there is some Spring IoC (or other IoC
container) feature that is missing in the T5 IoC and that can make any
difference. Could it be a (maybe obscure) missing feature the reason why
a few programmers find so hard to develop a module integration library?


I don't think so. IoC containers features are similar. Comparing  
Spring-Core, Tapestry-IoC and Guice, AFAIK, Spring has no feature that the  
others don't have. On the other hand, Spring is way older (1.0 released in  
2004!) and they have a company behind it, so they can pay people to work  
on it full time.


I still think it's more a matter of someone having the time and need.


Anyway, these are JM2C.


Thanks for contributing to the discussion. :)

--
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

Re: Discussion

2009-12-23 Thread Howard Lewis Ship

Noe, I've been down this path before, regrettably.  The ONLY thing to
do it to ignore the trolls.

On Tue, Dec 22, 2009 at 11:29 PM, Newham, Cameron cameron.new...@bl.uk wrote:
 I don't agree with the OP that the ServerSide discussion shows Tapestry has 
 lost the battle - two posters state they don't want to see Tapestry 
 mentioned. That's all there is.

 However, I can't agree with you Thiago. The old saying is if you say it 
 enough times then people will believe it is true.

 If you are just going to stand by and let trolls post bad things about 
 Tapestry unchallenged then they have won the argument - regardless of how bad 
 their argument may be and how incorrect their views may be.

 After all, someone pitching up and wanting a framework will read what they've 
 written and believe it. Who is to say these anti-Tapestry people are wrong?  
 Not you - because you won't counter their arguments! :-)

 Sure - don't feed the trolls. But all that is necessary is to say something 
 positive; not engage them in an argument.

 Merry Xmas everyone.


 -Original Message-
 From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com]
 Sent: 22 December 2009 15:26
 To: Tapestry users
 Subject: Re: Discussion

 Em Tue, 22 Dec 2009 12:45:20 -0200, Banchi Liko banchi...@gmail.com
 escreveu:

 Hi guys,

 Hi!

 There is a discussion going on here
 http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems
 like Tapestry ihas already been ruled out as a viable and serious web
 framework.

 TheServerSide comments has too many trolls to have a good, reasonable
 discussion there.

 Wicket seems to be the favorite.

 Some people who bother to post there like Wicket. Most people who like
 Tapestry, maybe all of them, don't bother to post there.

 I'm sad Tapestry has lost the battle and afraid it might die soon.

 Please source or explain your statements or you'll be treated like a troll
 here.

 Please go and contribute and let your voice be
 heard before Tapestry dies a horrible death.

 No, thank you. Posting there will not change Tapestry's fate. Using it,
 exchanging ideas in the mailing lists and contributing code will (and
 already is).

 --
 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





-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

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

Re: Discussion

 Select models out of beans could be improved. My Tapestry CRUD package has a
 solution for that.

I know... but your CRUD package is not tapestry.

 You're talking about a snapshot. This behaviour was changed and now
 everything in the context is allowed.

Hey.. this was no complain, you asked where documentation could be improved ;-)

 In the backend, it gets more complicated: contributing services,
 decorating services, overriding services...

 I don't think they're complicated.

That's your oppinion... my feeling is the opposite. On its own, these
things are simple - but in context of a complex framework like
tapestry, its hard to get the big picture.

 You should know I've tried ;-) BTW the libraries are spread all over
 the web (google code, kenai, github, tap360..).

 There are links to them in http://tapestry.apache.org/.

The problem is that tapestry.apache.org is static. It can be edited by
the commiters only. My feeling is that this forces the community to a
single place: the mailing lists. I am not sure if this is enough to
build an opensource community around a framework like tapestry.

Of course there is the wiki - but it is hidden behind lots of menu entries.

 CDI and JPA were released few weeks ago and they were mostly written to be
 used inside an EJB container. Implementing CDI is not a piece of cake.

JPA is available since over 3 years. And I disagree: it is not mainly
written to be used inside an EJB container.
JPA2 is new.. but maybe you know that there is a half-finnished module
available.

 All it does is to provide Spring beans as Tapestry services. :)

Not the other way as well(tapestry services as spring beans?) .. ?

 You're changing the output generated by some. Try to do the same in another
 framework. ;) The documentation could mention it, of course.

In other frameworks the output is not that static... and such basic
things like where to add the error messages is easy to change. Take
Struts2 for an example: s:error for=fieldNameError message for
Field/s:error

 There are many ways of modeling and implementing authentication and
 authorization, so I think it's not a Tapestry responsibility.

I think it is - security is something needed by the majority of
webapps.  Tapestry wants to be my web framework - so why doesn't it
help me? Using container based authentication is not possible. Its
hard for newbies to get around this. Not more and not less.

 Besides the proxy issue, you're wrong: it wouldn't be difficult to integrate 
 with Tapestry-Hibernate now it would be hard to something that would work 
 with other
 persistence options.

I was not aware of the proxy issue, but I was right that it can't be
too easy. Anyway, IMHO we should need to think about a more general
way of handling persistence. ORMs (aka JPA and Hibernate) are just one
part of the persistence arena..

 I strongly suggest you to not make bold statements about frameworks you
 don't know very well. ;) It makes you sound like an uninformed troll, but I
 know you're not one, as you made some very good points in this discussion.

If I sound like an uninformed troll, that is because I did not manage
to understand everything good enough. One possibility is that I am
just too dumb, the other one would be that tapestry is quite complex
(what is my whole point above)... (please resist to answer this
question ;-)

   Piero

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

Re: Discussion

Em Wed, 23 Dec 2009 15:42:20 -0200, Piero Sartini li...@pierosartini.de  
escreveu:



I know... but your CRUD package is not tapestry.


It's a Tapestry extension that I plan to contribute to Tapestry itself  
when is good enough (a.k.a. it has unit tests).



That's your oppinion... my feeling is the opposite. On its own, these
things are simple - but in context of a complex framework like
tapestry, its hard to get the big picture.


If it's possible and easy to do what you want but you don't know how, then  
I think we have an issue with the documentation, not with the framework  
itself.



The problem is that tapestry.apache.org is static. It can be edited by
the commiters only.


Just post a JIRA and it's added there.
Of course, a more dynamic page would be a nicer solution.

CDI and JPA were released few weeks ago and they were mostly written to  
be

used inside an EJB container. Implementing CDI is not a piece of cake.


JPA is available since over 3 years. And I disagree: it is not mainly
written to be used inside an EJB container.


I wrote that because of the @PersistenceContext. That's the only thing,  
AFAIK, that would be different from tapestry-hibernate.



JPA2 is new.. but maybe you know that there is a half-finnished module
available.


Yes, I know. :)


All it does is to provide Spring beans as Tapestry services. :)

Not the other way as well(tapestry services as spring beans?) .. ?


Tapestry-Spring supports both.


In other frameworks the output is not that static... and such basic
things like where to add the error messages is easy to change. Take
Struts2 for an example: s:error for=fieldNameError message for
Field/s:error


You can do this in Tapestry too, but not in the template. It goes in  
app.properties. From  
http://tapestry.apache.org/tapestry5.1/guide/validation.html


The first key checked is formId-fieldId-validatorName-message.
formId: the local component id of the Form component
fieldId: the local component id of the field (TextField, etc.)
validatorName: the name of the validator, i.e., required or minlength

If there is not message for that key, a second check is made, for  
fieldId-validatorName-message.


If that does not match a message, then the built-in default validation  
message is used.



I think it is - security is something needed by the majority of
webapps.  Tapestry wants to be my web framework - so why doesn't it
help me? Using container based authentication is not possible. Its
hard for newbies to get around this. Not more and not less.


I really dislike container-based authentication. I think it should be  
implemented by the application.



I was not aware of the proxy issue, but I was right that it can't be
too easy. Anyway, IMHO we should need to think about a more general
way of handling persistence. ORMs (aka JPA and Hibernate) are just one
part of the persistence arena..


The only part I can think that can be the same across different ORM  
frameworks is transaction handling. And a tapestry-tx package is a dream  
of mine.



If I sound like an uninformed troll,


You just sounded like a troll when you made several about why we don't  
have more integrations in Tapestry-IoC without writing one. The rest is a  
nice discussion. :)



that is because I did not manage
to understand everything good enough. One possibility is that I am
just too dumb,


I guess not. :)


the other one would be that tapestry is quite complex
(what is my whole point above)... (please resist to answer this
question ;-)


Different points of view, different minds, different opinions. Sorry, I  
answered your question. :)


--
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

Re: Discussion

 I wrote that because of the @PersistenceContext. That's the only thing,
 AFAIK, that would be different from tapestry-hibernate.

From a users perspective, its a matter of injecting EntityManager
instead of hibernate's Session.
In the module itself there are more changes.

 You can do this in Tapestry too, but not in the template. It goes in
 app.properties. From
 http://tapestry.apache.org/tapestry5.1/guide/validation.html

 The first key checked is formId-fieldId-validatorName-message.
 formId: the local component id of the Form component
 fieldId: the local component id of the field (TextField, etc.)
 validatorName: the name of the validator, i.e., required or minlength

 If there is not message for that key, a second check is made, for
 fieldId-validatorName-message.

 If that does not match a message, then the built-in default validation
 message is used.

Nope, that is the error message only. What I would like to define is
where the message should be rendered.. and control the markup ;-)
Right now, the client-side validation is kind of a blackbox. It
renders its bubbles with the messages... but if you don't want to have
these bubbles but your own markup, you need to do things like override
services you never heard about.

As said before, need to look at the ValidationDecorator again, but my
feeling still is that this is not as easy as it should be.
I really want to be able to define where my client-side error messages
should appear inside the template (very important: how the markup
should look like)

 I really dislike container-based authentication. I think it should be
 implemented by the application.

I don't like it as well - but tapestry should provide an alternative.
Maybe the question is if tapestry wants to be a full-stack framework
or just deliver some building blocks. For being a full-stack
framework, there is not enough functionality available. To just
provide building blocks, it dictates too much (javascript library,
markup, and so on). Of course this is just my feeling.

And don't get me wrong: I really like tapestry and hava already built
some projects with it. My reason for all this complaining is just to
make it even better :-)

 The only part I can think that can be the same across different ORM
 frameworks is transaction handling. And a tapestry-tx package is a dream of
 mine.

Different ORM frameworks do share much more in common: see JPA2 for
what is standardized between them.
For other persistence solutions (like OODBMs, Google BigTable, HBase
and so on) it gets more difficult... but JDO tries to provide a
standard for all persistence needings.

tapestry-tx could integrate with tapestry-jpa and tapestry-jdo ,-)

Piero

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

Re: Discussion

Em Wed, 23 Dec 2009 16:22:49 -0200, Piero Sartini li...@pierosartini.de  
escreveu:



I wrote that because of the @PersistenceContext. That's the only thing,
AFAIK, that would be different from tapestry-hibernate.


From a users perspective, its a matter of injecting EntityManager
instead of hibernate's Session.
In the module itself there are more changes.


I don't know Tapestry-IoC from the inside (yet!), so I don't know how  
difficult it would be to provide an injection for @PersistenceContext. It  
would be straightforward for @Inject.



Nope, that is the error message only. What I would like to define is
where the message should be rendered.. and control the markup ;-)


This is done by ValidationDecorator. You can implement your own one and  
overrid the DefaultValidationDecorator contribution to the  
MarkupRenderer service. I have not tested yet, though.



Right now, the client-side validation is kind of a blackbox. It
renders its bubbles with the messages... but if you don't want to have
these bubbles but your own markup, you need to do things like override
services you never heard about.


Or disable client-side validation entirely. Agreed with the rest.


As said before, need to look at the ValidationDecorator again, but my
feeling still is that this is not as easy as it should be.
I really want to be able to define where my client-side error messages
should appear inside the template (very important: how the markup
should look like)


More freedom, more control, more complex. Quite hard to avoid that.


I don't like it as well - but tapestry should provide an alternative.
Maybe the question is if tapestry wants to be a full-stack framework
or just deliver some building blocks. For being a full-stack
framework, there is not enough functionality available. To just
provide building blocks, it dictates too much (javascript library,
markup, and so on). Of course this is just my feeling.


I cannot speak for the project, but I think Tapestry tries to be a Web  
framework, not a full stack. At least not yet. ;)



And don't get me wrong: I really like tapestry and hava already built
some projects with it. My reason for all this complaining is just to
make it even better :-)


:)


Different ORM frameworks do share much more in common: see JPA2 for
what is standardized between them.
For other persistence solutions (like OODBMs, Google BigTable, HBase
and so on) it gets more difficult... but JDO tries to provide a
standard for all persistence needings.


I was talking about a really generic tapestry-tx that could be used with  
any persistence technology, being it backed by relational database or not.
IMHO, using JPA or JDO over a non-relational database loses some of the  
benefits of it. I plan to write some projects to run on Google Application  
Engine and I'm going to use the low-level API.



tapestry-tx could integrate with tapestry-jpa and tapestry-jdo ,-)


That's my plan. ;)

--
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

Re: Discussion

 More freedom, more control, more complex. Quite hard to avoid that.

Agreed. The challange is to define what parts need to be customized
often, and should be easy to change. For me, these bubbles should be
easy to change..  but as always, others may have a different oppinion.

 I cannot speak for the project, but I think Tapestry tries to be a Web
 framework, not a full stack. At least not yet. ;)

For me, authentication is an important part of a web framework and
should provide some standard way to do so.

 I was talking about a really generic tapestry-tx that could be used with any
 persistence technology, being it backed by relational database or not.

Great! Really looking forward to this.

 IMHO, using JPA or JDO over a non-relational database loses some of the
 benefits of it. I plan to write some projects to run on Google Application
 Engine and I'm going to use the low-level API.

Agreed. The native APIs are much easier in many cases. JPA as a whole
does not even fit well with non relational databases. JDO on the other
hand does - it was designed from the ground up to support different
types of persistence engines.

  Piero

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

Re: Discussion

Em Wed, 23 Dec 2009 17:37:24 -0200, Piero Sartini li...@pierosartini.de  
escreveu:



For me, authentication is an important part of a web framework and
should provide some standard way to do so.


Wicket itself doesn't. Nor does JSF. (all this as far as I know and I  
google it)


There is a third-party package for Wicket:  
http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security.


For Tapestry, there's ChenilleKit Access:  
http://www.chenillekit.org/chenillekit-access/



Great! Really looking forward to this.


Me too. :)


JDO on the other
hand does - it was designed from the ground up to support different
types of persistence engines.


I never paid attention to JDO. Wouldn't be the case case as JPA regarding  
use of low-level APIs?


Regarding JDO, its implementations need for class enhancement after  
compilation is something very annoying. Am I right?


--
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

Re: Discussion

 Wicket itself doesn't. Nor does JSF. (all this as far as I know and I google
 it)

JSF does not qualify as framework IMHO. Seam brings security.
Agreed on chenillekit.

By the way, it would be nice to have something like wicketstuff.org :-)

 Regarding JDO, its implementations need for class enhancement after
 compilation is something very annoying. Am I right?

Yes, you are. Just wanted to mention that there is something not that
RDBMS specific than JPA.
I think I would prefer the native APIs as well - or maybe NeoDatis v2
if there exists a backend for the db to use. I like the easy to use
api and the clean queries.

   Piero

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

Re: Discussion

2009-12-23 Thread Sergey Didenko

A few thoughts from this discussion:

Tapestry site needs:

1. immediately visible search field over all valuable resources, like wiki.
We were discussing custom google search that makes it.

2. A few more diagrams, like
http://tapestry.apache.org/tapestry5.1/images/component-render-states.png

Re: Discussion

Em Wed, 23 Dec 2009 19:19:17 -0200, Alfonso Quiroga  
alfonsose...@gmail.com escreveu:



Hi! very interesting thread. I use T5 since 1 year aprox, and it's
true that T-IOC was the first wall I had, now I understand it and I
like it a lot (my system does NOT use spring, all with t-ioc). I don't
know which is the solution, because there is documentation about
t-ioc, but maybe more documentation? or maybe a demo-project that uses
basic t-ioc. I think is easier seeing something working, than reading
t-ioc documentation and start from scratch.


Better documentation and examples are a very good idea. :)
Demo projects would really help. Something like the Guice introduction  
would be nice.



Another point.. I think it's impossible to use T5 without t-ioc, is
this right? If it's possible, it would be a good idea uploading
another demo-project without t-ioc.


It's impossible. T5 uses T-IoC in every way possible. T-IoC was created  
for T5 because none of the IoC containers at that time provided everything  
T5 needs.



What else? js.. prototype-based, I know it's possible to have
prototype+jquery together, but I can see lot of people heading jquery,
so I have a long-term plan.. make a tapestry.js based on jquery, if I
do it obviously I'll share it.


There's a plan not to switch from Prototype to jQuery. There's a plan to  
have JavaScript stacks, one implemented with Prototype, another with  
jQuery. No dates yet.



But the solution for this would be a tapestry.js agnostic, so people
can inject their favourite framework. So, maybe it could be shipped
with a default prototype injection, but anyone could write a mootols
injection, jquery injection, etc etc


The plan looks like your description. :) Lot of work to implement it,  
though. It would be almost something like a JavaScript framework  
abstraction layer.



Last, it would be good more components (ui components).


Agreed. Don't forget to check the third-party packages in the Tapestry  
home page.


--
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

Re: Discussion