Tapestry 6: Famous last words?
I saw the following comment on Howard's blog and felt compelled to comment: "I just felt the need to reiterate that I don't see there ever being a T6; I see a stream of backwards compatible updates to Tapestry 5.1. In fact, I think the 5.0 -> 5.1 transition was a little rougher than I'd like for future releases." "The overall approach in T5 was to eliminate the root issues that caused the backwards compatibility problems in earlier Tapestries." Aside from the fact that there is an admittance to things not going as planned in the very first version 5 iteration, Howard, I think you are sincerely wrong. For based upon your resolve to never have a version 6, I see only two possible outcomes: a) All innovation on the web stops and we continue using T5 b) Innovation on the web continues and Tapestry becomes obsolete. To further my argument, assume that T5 had been developed in 1995 for use on the web. Do you really see T5 honed for the web as of 1995 being able to seamlessly take on, without change in architecture, the following: - CSS - Javascript evolution - Ajax - IoC - Persistence frameworks The problem with backwards compatibility is introduced at some point in every framework for one of two reasons: a) The framework decides to adopt a new architecture to support essentially the same end goal and platform for gains in productivity, stability, scalability, etc. b) The framework is forced to adopt a new architecture to support innovation in the marketplace (HTML5, offline storage, desktop-web-apps, RIA, osgi/java modules/bundles, language improvements, who-knows-what). The technology community is accepting of (b) as a necessary side effect of rapid innovation. It is far more skeptical of (a). However, companies are free to attempt (a) since in a free market, the market decides. Open source is not immune to that. So while I find your goal sincere given the v3 -> v4 -> v5 migration history, I see it as neither a realistic nor intelligent goal to pursue. In fact, quite the contrary, it dissuades people who are evaluating Tapestry. Instead of defending your decision to make T5 with the cloak of eternal future compatibility, why don't you admit to your error and move on? A little humility would be of great benefit and would complement your intellectual prowess, which is self-evident in your works. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
For Tap 3, we had a very elaborate form with loop implementation and we added Ajax-validation such that you only write validation code once in Java and for javascript validation, an ajax call is made to run the same validation code and bring back the results. The error handling could correctly handle n-input fields in a form all generated via a loop. Needless to say the code was quite complex and horrendously convoluted and now is outdated :( haha -- From: "Inge Solvoll" Sent: Thursday, April 30, 2009 6:09 PM To: "Tapestry users" Subject: Re: T5: What is NOT beautiful about Tapestry? Agree with Alex on the last comment about proving that issues don't exist! I have one example of a trivial thing that I have found difficult to implement in all Tapestry versions I have used(3, 4, 5): - A form with a loop in it. This is extremely common in the pages I make, and my mind always struggles when trying to find how this is done in the new Tapestry version. I never figured out a way to do it in 3 and 4 that made sense to me and looked correct. It also happened in T5. Maybe I'm stupid, but I really had to struggle hard to track down the details needed to implement this correctly, using encoders, initializing my form objects in the correct method in the correct way, and so on. I didn't find an example in the docs showing me the best practice for this (for me) very trivial and very common pattern. On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev wrote: I will echo Kranga's #1 and #2 and add a couple. I'm all for convention over configuration, but when you have to dig out the convention out of source code, mailing list, or somewhere else, I'd wish I had a well defined interface that I could just implement. The not-so-pojo aspect becomes too apparent when you have to write some test cases against the said components and you start scratching you head about "now, how do I make all of those magical annotations work if I don't do the whole IoC bit where it will inject everything". One additional difficulty is that T5's model is so different in respect to AJAX that it takes a while to wrap (or warp) your head around what you need to do in order to do something seemingly simple w/ a known Javascript framework (e.g. think Dojo, Prototype, jQuery). There are a plethora of people out there that know how to make up a snazzy ajaxy interface; however, when it comes down to T5 you have to jump through a couple of hoops just to get the URL to which the Ajax code will hook into (e.g. the componentResources.createPageLink , createEventLink, etc). Componetization support and all within T5 is nice, but when you have to climb a big hill of learning a lot of T5 before you can do a silly autocompletion example for Dojo or jQuery, it just makes it harder than necessary. Certainly not a boon. Finally, it's great that T5 is so well decomposed into small interfaces , so that you can override anything you want. However, too many small classes/interfaces + a bunch of dependencies on each other (which are really easy to do when IoC can magically inject dependencies for you) starts being a drag when you want to implement/override one, and then you realize that in order to do one, you need to figure out a bunch more things that need to be injected (or something like that). It's really easy to get into a rabbit hole of "oh, I wanted to implement this one thing, now I have to understand these other three before I can implement the first one" Otho, I don't think the point of this thread is for us to prove that the issues that are brought up are not actually issues. The fact that people bring them up, means that those issues still exist. I doubt that someone will go through the trouble of typing up a big email regarding his troubles w/ T5 if these were not issues that he/she has dealt with. Cheers, Alex K On Thu, Apr 30, 2009 at 9:28 AM, kranga wrote: > 1) Documentation: It is one thing to remove dependencies on framework > interfaces but quite another to leave the developer hanging with no > documentation. Programming by convention is programming in the dark if the > convention is not known. > 2) Although Tapestry claims to be POJO, you still have to have a > contract > (whether it is methods by convention or annotated methods). In the long run > whether this is really better than interface implementation is not > fully > proven (much like the current debate of whether dynamically typed languages > will prove more difficult to maintain in the long run). > 3) Lack of a component marketplace: Wow, 4 years on and this is still > on my > list. We wrote a gigantic application in Tapestry 3 which is still in > production. But we've decided to write all new apps in JSF with the aim of > quickly adopting 2.0 when the spec is r
Re: T5: What is NOT beautiful about Tapestry?
1) Documentation: It is one thing to remove dependencies on framework interfaces but quite another to leave the developer hanging with no documentation. Programming by convention is programming in the dark if the convention is not known. 2) Although Tapestry claims to be POJO, you still have to have a contract (whether it is methods by convention or annotated methods). In the long run whether this is really better than interface implementation is not fully proven (much like the current debate of whether dynamically typed languages will prove more difficult to maintain in the long run). 3) Lack of a component marketplace: Wow, 4 years on and this is still on my list. We wrote a gigantic application in Tapestry 3 which is still in production. But we've decided to write all new apps in JSF with the aim of quickly adopting 2.0 when the spec is released. The main reason - a plethora of components to choose from. 4) Developer mindshare: Our analysis with Tapestry 3 shows that for every developer we hire, we have to write off 2-4 weeks until they become well versed in Tapestry. I don't believe T5 will be any different. You cannot argue against a standard like JSF that is supported by vendors. The lack of penetration of JSF speaks to its terrible initial design which hopefully will be rectified in 2.0 I don't believe Tapestry will dwindle and die but I don't see it becoming the defacto standard ala Struts in the early 2000s. -- From: "Pedro Januário" Sent: Thursday, April 30, 2009 5:43 AM To: "Tapestry users" Subject: Re: T5: What is NOT beautiful about Tapestry? I totally agree with Hugo's ideia. The wiki sounds good and should be a easy to make documentation about common problems. 2009/4/30 Hugo Palma I agree a book would be great, what happened to the tapestry5-book project http://code.google.com/p/tapestry5-book/ ? Still, i think a lot better could be done with the online documentation. I believe the structure of the online documentation should be very similar to a book, it should start with the basics and evolve to more "hardcore" stuff from there. Just the fact that the current documentation is structured with only one level of depth and the list of item is ordered alphabetically makes the task of finding some information much more difficult. I for example really like how the hibernate documentation is structure, i usually have to problem finding what i'm looking for there. So, maybe the wiki could be a starting place for the birth of a documentation with such a structure. On Thu, Apr 30, 2009 at 10:06 AM, Blower, Andy wrote: > I think you hit the nail on the head Carl. The documentation is okay generally (some bits poor, some very good) but there is not enough to tie it all together and guide new developers so they know what they can do with T5. I'm not convinced that the main documentation should attempt this on its own, or whether it should strive to be a great reference with some more higher level introductory/discovery bits along with a good published book to handle introducing everything and tying it together. Having the only published book for T5 being so out of date is a huge problem for the framework in my opinion. > > I don't think a wiki is the answer to this, I really like knowing that the documentation that I'm looking at is for a specific version of Tapestry and is updated when the code is - I would not want to lose that. > > Andy. > >> -Original Message- >> From: Carl Crowder [mailto:carl.crow...@taptu.com] >> Sent: 29 April 2009 22:04 >> To: Tapestry users >> Subject: Re: T5: What is NOT beautiful about Tapestry? >> >> Discovery of it's parts. Franky the documentation is lacking and even >> with reading the mailing list, reading the howtos wiki, buying the >> Tapestry 5 book and working with it for over a year I still come >> across >> things I never knew existed that would have solved a problem I've had. >> I >> often spend ages writing something myself after searching for a >> solution. >> >> What's beautiful about Tapestry? That almost every problem has a >> simple >> solution built in. What's not beautiful about Tapestry? That I >> generally >> find these solutions by accident, and way after I've written my own! >> >> Lots of things are obvious and easy to understand once you know what >> they are but it's learning what they are that is the problem. I've >> been >> waxing lyrical about Tapestry where I work and while the developers >> who >> tried it love it, their main gripe is always that it's difficult to >> understand what it can do. >> >> The cookbook is the right idea but it's only got 5 entries right now. >> It >> needs to be way more comprehensive >> >> Inge Solvoll wrote: >> > Hi! >> > >> > I have been reading the "beautiful" thread and added my opinion >> > about >> what's >> > great about Tapestry. It's nice to sum up why we all are so excited >> about >> > this, it obviou
Re: [Tapestry 5.0.15] - Hidding client-side validation
The issue here is that you chose to implement a very specific paradigm (pop ups) to display error messages which almost always will be the wrong paradigm because every website and design expression will require something different. So everyone is going to try to override the basic settings - Original Message - From: "Howard Lewis Ship" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Saturday, November 01, 2008 6:47 PM Subject: Re: [Tapestry 5.0.15] - Hidding client-side validation This can be done by "monkey patching" the Tapestry JavaScript. You can have a JS library that overwrites the definitions of some of the built-in Tapestry functions related to validation. In this way, you can prevent the pop up bubbles, or change how the validation messages are presented to the user. On Thu, Oct 30, 2008 at 1:36 AM, Antonio Fernández - STAR Málaga <[EMAIL PROTECTED]> wrote: Hi again ! Many thanks for you fast asnwer , i tryed your option , but this is not the behaviour i want. Now the submit action happens when one or more TextFields are empty, and with clientValidation=true the submit is not completed. I want the behaviour of clientValidation=true, but simply hidding the Validation Messages. Greetings & Nice Day Sven Homburg escribió: have a look in the "Form" component description (parameter "clientSideValidation") http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/Form.html 2008/10/30 Antonio Fernández - STAR Málaga <[EMAIL PROTECTED] Hi All & Good Morning :-) Is there a way for hidding the JavaScript Validation Messages on the Client-Side ? Greetings Passi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The URL encoding issue
As long as your custom scheme can also handle UTF-8 standard scheme so that libraries that we integrated with (JS libraries and others) that produce encoded URLs don't break. - Original Message - From: "Massimo Lusetti" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Saturday, October 25, 2008 6:22 PM Subject: Re: The URL encoding issue On Fri, Oct 24, 2008 at 7:01 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: BTW, I'm actively working on the issue with URL encoding/decoding. Because of the differences between Jetty and Tomcat, I'm abandoning standard URL encoding (i.e., %2f and all that) and using my own scheme. As a side effect, we can now properly support null and blank string values in page activation and event contexts (they will appear in URLs as $N and $B, respectively). It's somehow between strange and sad to have this issues again and again but that seems to have come out nice, as usual. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] How to get to ApplocationGlobals and ServletContext
ApplicationGlobals cannot be injected into RequestFilter. Inject RequestGlobals into it instead or inject ApplicationStateManager (?) into it. - Original Message - From: "Eric Ma" <[EMAIL PROTECTED]> To: Sent: Friday, October 03, 2008 9:31 AM Subject: [T5] How to get to ApplocationGlobals and ServletContext I have a custom RequestFilter, which authenticates users and checks for user roles, and is applied to all pages. To avoid database hit on every request, authenticated user is cached in Acegi SecurityContextHolder. Now, another part of the app allows admins to update user roles, adding or removing privileges. When that happens, I set a flag in ServletContext for user roles being dirty, forcing the user to be re-authenticated. So what I need to do is that in my RequestFilter, retrieve the flag from ServletContext. The problem I am running into is that the injected ApplicationGlobals in my RequestFilter is null. My questions are a) is ApplicationGlobals injectable in a RequestFilter, and b) if not, is there a way to get hold of ServletContext somehow? Thanks, Eric -- View this message in context: http://www.nabble.com/-T5--How-to-get-to-ApplocationGlobals-and-ServletContext-tp19797812p19797812.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry App Replication
The extensive use of @Persist("flash") for form fields could cause thrashing
in an app cluster. That's one piece I'd like to see refined in Tapestry to
be one in a different way.
- Original Message -
From: "Howard Lewis Ship" <[EMAIL PROTECTED]>
To: "Tapestry users"
Sent: Monday, September 08, 2008 12:59 PM
Subject: Re: Tapestry App Replication
Tapestry is designed to be "a good citizen" of an application server
that supports clustering. It's careful about what it writes into the
HttpSession. The framework understands that the server that receives
a request may not be the same one that rendered the page initially;
this knowlege affects many code paths, and the approach Tapestry takes
to caching and pooling page instances.
Your part is to properly manage the objects put into the HttpSession
(via @ApplicationState or @Persist). These objects should be
immutable where possible (i.e., String, or a primitive or wrapper
type). For @Persist, if you change the internal state of a mutable
object, you should reassign the field, to ensure that Tapestry knows
to update the HttpSession (and force the value to be serialized and
distributed around the cluster).
Still, sticky sessions are the way to go when possible. Much more
efficient use of resources ... you are scaling *out* not *up* which is
always cheaper.
Again, Tapestry is a good citizen, but from the application server's
point of view, it's just another servlet application. The heavy
lifting here is application server specific.
On Mon, Sep 8, 2008 at 4:44 AM, Carl Crowder <[EMAIL PROTECTED]>
wrote:
Hi all,
Is it possible to run multiple instances of a Tapestry app on various
servers, but have them share session and application state?
Carl
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: index page in pages package acts as a catchall
Oddly enough using Start instead of Index handles this situation correctly. - Original Message - From: "Lutz Hühnken" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Thursday, July 31, 2008 5:16 AM Subject: Re: T5: index page in pages package acts as a catchall Dear Chris, Ends up as http://app.com/. Am I doing something wrong? Surely others have run into this and deem it undesirable, no? yes and yes. It has been discussed on this list before and a workaround (that works well for me) has been proposed. You can see the thread here: http://www.nabble.com/Index-page-context-and-404-response-to16649174.html#a16649174 Described very roughly: Assuming your index page is not meant to be called with parameters - if parameters are given, the user was probably actually requesting a non-existing page. So if index is called with parameters, reply with a 404 not found. Hth, Lutz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Integrating T5 webapp with Axis2 webservice framework
Also checkout Apache CXF - with its full Jaxws annotations support and spring integration, it is silly easy to turn a class into a web service. - Original Message - From: "Mahen Perera" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Friday, July 11, 2008 6:44 AM Subject: RE: T5: Integrating T5 webapp with Axis2 webservice framework Not sure if this helps.. From what I know, Tapestry does its core of work in the Tapestry Filter,. So, if you add this filter in to the filter list of the Axis Servlet, ,,, so that the Tapestry filter kicks in before the request goes to Axis, Then you should be able to get the Tapestry features .. I might be missing something here tho. -Original Message- From: Andreas Pursian [mailto:[EMAIL PROTECTED] Sent: 11 July 2008 11:21 To: Tapestry users Subject: T5: Integrating T5 webapp with Axis2 webservice framework Dear list, i'am working on a webapp which should be accessible through a normal html based interface and a webservice component. I use a couple of business delegate classes to seperate presentation and domain layer which i @Inject as a service into my page classes on the one hand and into my webservice skeleton classes on the other hand. So the problem is, while all webservice requests are handled by the AxisServlet, T5 IoC can't handle the injection for the businessdelegate classes. So my question is, if somebody knows a elegant solution for integrating T5 and Axis2 to give webservice skeletons access to T5 services. thank you in advance Andreas -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T4] tapestry-captcha source?
You should be able to implement recaptcha in minutes. The recaptcha.net website points to java library to - very simple and very effective (supports audo playback as well). - Original Message - From: "Kalle Korhonen" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Saturday, July 05, 2008 7:11 PM Subject: [T4] tapestry-captcha source? Hey, anybody happen to have the source for James Carman's tapestry-captcha? Just started seeing a need for some type of captcha-functionality only to find out that http://www.carmanconsulting.com/mvn/com/javaforge/tapestry/tapestry-captcha/returns 404 and javaforge's tapestry project is non-functional. I'd gladly take a look at that implementation or any other and adapt to my needs rather than writing a completely new one. Thanks, Kalle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 version 5.0.13 Index page suppressing other servlets?
Thiago,
I think a better statement would be "Tapestry is behaving exactly as it
wants to." I guess this is a very unfortunate side-effect of the way
Tapestry uses contexts. The design is fine when the web-app consists only of
Tapestry, but that is seldom the case in real-world applications.
This still doesn't explain why I don't see this behavior when using a Start
page. Can a start page not have activation context?
- Original Message -
From: "Thiago H. de Paula Figueiredo" <[EMAIL PROTECTED]>
To: "Tapestry users"
Sent: Wednesday, June 25, 2008 10:49 AM
Subject: Re: T5 version 5.0.13 Index page suppressing other servlets?
Em Wed, 25 Jun 2008 11:32:05 -0300, kranga <[EMAIL PROTECTED]> escreveu:
I have Index.tml setup in my app root for the home page. I also have a
servlet defined that listens to requests to /broker. There is no folder
by the name of /broker. I find that Tapestry takes over the /broker
request and serves up the home page! Unless there is a /broker folder
with some file Tapestry takes over! Why is the Tapestry servlet
over-reaching and is there any configuration to prevent it from doing so?
NOTE: This behavior is not present when I use Start.tml as my home page.
Tapestry is behaving exactly as it should. For any request, the Tapestry
servlet filter (it is not a servlet), checks if the request can be handled
by it. If it cannot, it just ignores it, giving a chance to other servlet
filters and servlets to process the request.
Having an Index page, Tapestry receives a request to /broker and thinks
that "broker" is the activation context for the Index page.
You can leave your Index page and tell Tapestry to ignore requests to
/broker adding this lines to you AppModule:
public static void
contributeIgnoredPathsFilter(UnorderedCollection configuration) {
configuration.add("/broker/.*");
}
More details at the end of
http://tapestry.apache.org/tapestry5/tapestry-core/guide/conf.html.
Thiago
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
T5 version 5.0.13 Index page suppressing other servlets?
I have Index.tml setup in my app root for the home page. I also have a servlet defined that listens to requests to /broker. There is no folder by the name of /broker. I find that Tapestry takes over the /broker request and serves up the home page! Unless there is a /broker folder with some file Tapestry takes over! Why is the Tapestry servlet over-reaching and is there any configuration to prevent it from doing so? NOTE: This behavior is not present when I use Start.tml as my home page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 5.0.13 Javascript rendering at end of document - questions regd
Kristian,
Thanks! That will work just fine. I suspected performance was the driver
but was hoping that there was a way of selectively adding some script
includes to the top!
- Original Message -
From: "Kristian Marinkovic" <[EMAIL PROTECTED]>
To: "Tapestry users"
Sent: Wednesday, June 25, 2008 8:22 AM
Subject: Re: T5 5.0.13 Javascript rendering at end of document - questions
regd
reason for adding js libraries at the end of the document:
https://issues.apache.org/jira/browse/TAPESTRY-2364
you could write an own Flash component that adds the js
libraries into the head section:
public class Flash() {
beginRender(MarkupWriter writer) {
Document d = writer.getDocument();
Element head = d.find("html/head");
head.element("script", ...);
}
}
i think you get the idea
g,
kris
"kranga" <[EMAIL PROTECTED]>
25.06.2008 14:02
Bitte antworten an
"Tapestry users"
An
"Tapestry users"
Kopie
Thema
Re: T5 5.0.13 Javascript rendering at end of document - questions regd
Filip,
That will not work because 1) the Flash player javascript is called
in-line to render the Flash player and 2) within the flash player
javascript, I've got some dynamic parameters being added. I can rework (2)
to make it a function parameter and put the dynamic nature in the inline
function call but that will still fail. Here is why:
HTML tags
renderFlashPlayer(${myParam})
Other HTML tags ...
So if renderFlashPlayer lives in flashPlayer.js, it will simply not work!
My
only alternative is to manually include flashUtil.js in the header and
inline flashPlayer.js. This is unnatural and against the grain. I suspect
that there are other similar scenarios.
- Original Message -
From: "Filip S. Adamsen" <[EMAIL PROTECTED]>
To: "Tapestry users"
Sent: Wednesday, June 25, 2008 7:51 AM
Subject: Re: T5 5.0.13 Javascript rendering at end of document - questions
regd
Actually, you can just put the JavaScript in a .js file and then include
it with @IncludeJavaScriptLibrary. Then add a call to
RenderSupport#addScript in your page's afterRender handler that does the
setup you need.
For this and more, check
http://tapestry.apache.org/tapestry5/tapestry-core/guide/ajax.html.
-Filip
On 2008-06-25 13:46, kranga wrote:
One more addition: When including the flash player in a page, the
recommended technique is to put inline javascript that renders the
flash
player where the javascript appears in the page. The javascript relies
on
an external javascript file being included. If I do an asset injection
of
the Flash javascript, it ends up at the bottom of the page and the
flash
player inline javascript fails. So it seems like one would need to
override this behavior. Otherwise I'd have to package up the inline
javascript as a method, inject that and then call it in place. But I'm
concerned with putting all the javascript for the flash in a Java file.
That is not a natural fit.
I have some questions regarding the decision to render Javascript at
the
end of the document:
1) What was the rationale/dirver for this?
2a) The upgrade notes say to use RenderSupport. Can anyone provide a
short description of how to use RenderSupport to inject a simple
javascript function?
2b) This implies that a lot of inline javascript will have to be moved
from .tml to .java classes. It seems this will reduce the
"naturalness"
of being able to use javascript normally.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 5.0.13 Javascript rendering at end of document - questions regd
Filip,
That will not work because 1) the Flash player javascript is called
in-line to render the Flash player and 2) within the flash player
javascript, I've got some dynamic parameters being added. I can rework (2)
to make it a function parameter and put the dynamic nature in the inline
function call but that will still fail. Here is why:
HTML tags
renderFlashPlayer(${myParam})
Other HTML tags ...
So if renderFlashPlayer lives in flashPlayer.js, it will simply not work! My
only alternative is to manually include flashUtil.js in the header and
inline flashPlayer.js. This is unnatural and against the grain. I suspect
that there are other similar scenarios.
- Original Message -
From: "Filip S. Adamsen" <[EMAIL PROTECTED]>
To: "Tapestry users"
Sent: Wednesday, June 25, 2008 7:51 AM
Subject: Re: T5 5.0.13 Javascript rendering at end of document - questions
regd
Actually, you can just put the JavaScript in a .js file and then include
it with @IncludeJavaScriptLibrary. Then add a call to
RenderSupport#addScript in your page's afterRender handler that does the
setup you need.
For this and more, check
http://tapestry.apache.org/tapestry5/tapestry-core/guide/ajax.html.
-Filip
On 2008-06-25 13:46, kranga wrote:
One more addition: When including the flash player in a page, the
recommended technique is to put inline javascript that renders the flash
player where the javascript appears in the page. The javascript relies on
an external javascript file being included. If I do an asset injection of
the Flash javascript, it ends up at the bottom of the page and the flash
player inline javascript fails. So it seems like one would need to
override this behavior. Otherwise I'd have to package up the inline
javascript as a method, inject that and then call it in place. But I'm
concerned with putting all the javascript for the flash in a Java file.
That is not a natural fit.
I have some questions regarding the decision to render Javascript at the
end of the document:
1) What was the rationale/dirver for this?
2a) The upgrade notes say to use RenderSupport. Can anyone provide a
short description of how to use RenderSupport to inject a simple
javascript function?
2b) This implies that a lot of inline javascript will have to be moved
from .tml to .java classes. It seems this will reduce the "naturalness"
of being able to use javascript normally.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 5.0.13 Javascript rendering at end of document - questions regd
I take that back. Putting the flash player inline javascript in a method will not help since when it is called, the flash player external javascript will still not have been processed. So now I'm forced to statically or conditionally include the flash player javascript in my layout at the top. This defeats the goal of allowing components to contribute javascript to a page. I think a mechanism to override the inclusion of javascript at the bottom of the page is needed. There are far too many javascript utilities that have been written that will fail to work in the mode. And I suspect almost all inline-rendering techniques that depend on an included javascript file will fail. One more addition: When including the flash player in a page, the recommended technique is to put inline javascript that renders the flash player where the javascript appears in the page. The javascript relies on an external javascript file being included. If I do an asset injection of the Flash javascript, it ends up at the bottom of the page and the flash player inline javascript fails. So it seems like one would need to override this behavior. Otherwise I'd have to package up the inline javascript as a method, inject that and then call it in place. But I'm concerned with putting all the javascript for the flash in a Java file. That is not a natural fit. I have some questions regarding the decision to render Javascript at the end of the document: 1) What was the rationale/dirver for this? 2a) The upgrade notes say to use RenderSupport. Can anyone provide a short description of how to use RenderSupport to inject a simple javascript function? 2b) This implies that a lot of inline javascript will have to be moved from .tml to .java classes. It seems this will reduce the "naturalness" of being able to use javascript normally. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5 5.0.13 Javascript rendering at end of document - questions regd
One more addition: When including the flash player in a page, the recommended technique is to put inline javascript that renders the flash player where the javascript appears in the page. The javascript relies on an external javascript file being included. If I do an asset injection of the Flash javascript, it ends up at the bottom of the page and the flash player inline javascript fails. So it seems like one would need to override this behavior. Otherwise I'd have to package up the inline javascript as a method, inject that and then call it in place. But I'm concerned with putting all the javascript for the flash in a Java file. That is not a natural fit. I have some questions regarding the decision to render Javascript at the end of the document: 1) What was the rationale/dirver for this? 2a) The upgrade notes say to use RenderSupport. Can anyone provide a short description of how to use RenderSupport to inject a simple javascript function? 2b) This implies that a lot of inline javascript will have to be moved from .tml to .java classes. It seems this will reduce the "naturalness" of being able to use javascript normally. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5 5.0.13 Javascript rendering at end of document - questions regd
I have some questions regarding the decision to render Javascript at the end of the document: 1) What was the rationale/dirver for this? 2a) The upgrade notes say to use RenderSupport. Can anyone provide a short description of how to use RenderSupport to inject a simple javascript function? 2b) This implies that a lot of inline javascript will have to be moved from .tml to .java classes. It seems this will reduce the "naturalness" of being able to use javascript normally. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Instability in Tapestry 5.0.12-SNAPSHOT
Somebody likes fish :) +1 for the idea -1 for the fishiness of it! I would go with a distinguisher in the package other than the version so that come T6, new users are wondering "what on earth?" My suggestion would be org.apache.tapestry.ng(for Next Generation) or along the food line: org.apache.tapestry.mignon org.apache.tapestry.ribeye org.apache.tapestry.nystrip org.apache.tapestry.porterhouse you get the drift :) - Original Message - From: "Christian Edward Gruber" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Monday, May 19, 2008 6:22 PM Subject: Re: Instability in Tapestry 5.0.12-SNAPSHOT Again, the differences between T3, T4, and T5 are not really "versions" in the typical sense. They're different architectural bases. You might call them three different web frameworks entirely. So there should be no reason technically for them to overlap, and they should have three different packages. You might as well have them by three different codenames, at which point you have org.apache.tapestry.trout org.apache.tapestry.tuna org.apache.tapestry.tilapia Different frameworks, all under the Tapestry project. The fact that org.apache.tapestry.yellowtail shows up in four years should have no bearing on the other three. (again, not that it will, just making a point) Christian. On 19-May-08, at 17:59 , Markus Joschko wrote: I'm not against a package rename but against the version number. The only benefit of putting a version number in, is to help tap4 users now. But who will care about tap4 in 2 years? The version number will still be in the code base by then. If the official version number of tapestry is changing from 5 to 2011 or whatsoever, developers will at best be irritated by the tapestry5 package names On Mon, May 19, 2008 at 11:41 PM, Sven Homburg <[EMAIL PROTECTED] > wrote: markus, i voted for package renaming like "org.apache.tapestry5" but i go even conform with your mind. if i read the reason for the package renaming, i was relay alienated for that, but on the other side, i am not sure, its more easier for some tap4 user to migrate slowly to tap5. but i am not sure, in our real fast spinning world, if there are much developer they say "i migrate tommorow" and belive their own mind voice. 2008/5/19 Markus Joschko <[EMAIL PROTECTED]>: Looks like I am alone but I don't like the idea of putting version numbers into package names. In the highly unlikely case that there will be a tapestry 6 (not for technical but solely for marketing reasons ;-)) it might confuse developers. Are the classes in tapestry5 still valid or not? Only developers who will run tapestry4 and 5 in one webapplication might have the problem of distinguishing between the packages. I guess that they are the minority and it might be reasonable for them to read the class comments if they are in doubt which package belongs to which tapestry version. so -1 for a tapestry5 or v5. my 2cents, Markus On Mon, May 19, 2008 at 9:58 PM, Blower, Andy <[EMAIL PROTECTED]> wrote: I agree. -Original Message- From: Massimo Lusetti [mailto:[EMAIL PROTECTED] Sent: 19 May 2008 16:02 To: Tapestry users Subject: Re: Instability in Tapestry 5.0.12-SNAPSHOT On Mon, May 19, 2008 at 4:57 PM, Howard Lewis Ship <[EMAIL PROTECTED] > wrote: The question is: would it have been better to just broadly rename org.apache.tapestry to org.apache.tapestry5? There was quite a bit of discussion back on forth among the developers on this one. I would say yes. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- with regards Sven Homburg http://tapestry5-components.googlecode.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5 Form issues
Using IE 7: Form gets submitted even if there are client-side validation errors. Event bubbling side-effect: If you have a page that contains a form and a component A, and further if the component itself has a form, then if the component's form is submitted and you have a simple onValidateForm() method, that gets called for the component's form validation submission as well. Thats a not so pleasant side-effect ... on option would be allow a @Bubble annotation that should be present for an event handler to handle a bubbled event? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5 - How to get Servlet context init params
There are several references to using ApplicationDefaults, SymbolProvider etc. in past emails but nothing concrete. Is there any way of getting a handle to the ServletContextSymbolProvider in a page or AppModule? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: ASO in HttpServletRequestFilter
Obvious: Because you can't access the HttpServletRequest from within the RequestFilter to access methods such as getRequestUri() (needed by 3rd party library being called in the filter). If I didn't have access to the ASO manager, then I could write up the filter as a traditional Servlet filter. Why bother with the Tapestry filter chain in the first place? Or do I need to configure my servletRequestFilter to be "after" some other filter? If so, where do I find the list of these "after" "before" definitions? - Original Message - From: "Robert Zeigler" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Tuesday, May 13, 2008 10:43 AM Subject: Re: T5: ASO in HttpServletRequestFilter Why not use a RequestFilter, instead? You can access the ApplicationStateManager from withing a RequestFilter. Robert On May 13, 2008, at 5/139:41 AM , kranga wrote: Version: 5.0.11 It appears that if you inject an application state manager into an HttpServletRequestFilter and try to access an ASO, you get a null pointer exception since the Tapestry Request object has still not been set up. This means that if you do need to access an ASO, you are forced to use the session directly (and hence the session from within your pages too). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5: ASO in HttpServletRequestFilter
Version: 5.0.11 It appears that if you inject an application state manager into an HttpServletRequestFilter and try to access an ASO, you get a null pointer exception since the Tapestry Request object has still not been set up. This means that if you do need to access an ASO, you are forced to use the session directly (and hence the session from within your pages too). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5: Calling method with parameter in prop
In looking at converting from T3 to T5, I've to deal with constructs such
as:
class="ognl:menuClassName('home')" where getMenuClassName uses the
parameter to compare with the page's "id" passed in to determine if this is
the currentPage or not. So the template has multiple links with constructs
such as:
class="ognl:menuClassName('about')"
class="ognl:menuClassName('contact')" etc.
How do I do this in T5 given that prop bindings to methods cannot accept
arguments? I'm sure there is a workaround, I just can't seem to find one.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Persistence pains
We use a serialization strategy that zips the serialized form and base64 encodes it. We're yet to see a performance issue with the solution. The issue with persisting each field in separate parameter is obviously that of the number of such fields you are able to persist. - Original Message - From: "Dmitry Shyshkin" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Monday, May 05, 2008 4:48 AM Subject: Re: T5: Persistence pains The problem in "client" strategy that it used Serializable mechanism of jvm. Of cause it produce a lot of data (not getting in mind that most domain objects are not Serializable). I use own persistent strategy called 'parameter'. It is similar to "client" with follow exceptions. * It uses ValueEncoder to convert from Object to String and from String to Object. It save a lot of space, because for domain object only it id is persistent, which is rarely longer than 6 characters. * It persist each field in separate parameters (when "client" persist all data in parameter t:ac) . In this way it is similar to activation context's friendly url behavior. User see somethings like this http://somewhere.com/page?user=123&order=12&item=5 With help of this strategy I persist data between request to the same page. It solves both: problem with multiple browser tabs and problem with too many persistent fields in session. Ivan Dubrov wrote: Right. Most annoying things for us about “session” and “flash” scopes was that they don’t work in several tabs. And “client” can’t hold too much data. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Persistence pains
The biggest argument to be made for "request scope" state that is automatically (or framework assisted developer code) persisted in the page vs. the "flash" technique of Tapestry is when considering multiple browsers opened by the user with the same session. Every app that I've developed, we've had to diligently ensure that nothing other than "login" credentials were stored in the session and everything was persisted within the request. For T3, our team developed an elaborate set of components that made this trivial (including our own annotations based support). The fact that Tap 5 gets in the way of trying to have a very light session is a little disconcerting. The other side-effect of "flash" would be thrashing in a clustered environment. - Original Message - From: "Howard Lewis Ship" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Saturday, May 03, 2008 5:37 PM Subject: Re: T5: Persistence pains On Fri, May 2, 2008 at 6:36 PM, Joel Wiegman <[EMAIL PROTECTED]> wrote: Josh, Thanks for the great suggestions. I guess I'm still befuddled as to why a web framework would resist having a "request scope" so dilligently. It's not resistance, it's a different mindset, one that states that URLs should stand on their own in the browser and represent data to be presented to the user (i.e., render page requests) rather than behaviors to execute (the action requests). From what you describe, your activate event handler method should be able to load whatever additional data is needed and store it in simple component fields: that's your request scope. The fact that Tapestry links action requests to page requests is a separate issue. The goal is that if the user clicks the refresh button (the other annoying thing users do, besides hit the browser back button) that there won't be unexpected side-effects (such as, for instance, re-submitting an order, re-sending an email, etc., etc.). The "flash" scope appears to makes some intelligent guesses as to when you want your objects removed from the session, but the back-button-example I listed is one of quite a few reasons why making such guesses is a fools game. As we all know, HTTP is a request-response, stateless protocol, but Tapestry appears to be resisting storing state in one of the most basic constructs available in HTTP... the request. Anyone know why this is? Because we can store it inside ordinary fields instead? As you illustrated, I'm sure there are quite a few elaborate ways of dancing around the issue in any application (redundant checking, re-verification, passing "clearThisValue" flags around, etc.). None seem very elegant though (and would probably be associated with "this is why I'm doing this" comments). As for your activation context suggestions, those are some neat ideas. I hadn't considered your "marking" suggestion. I'm a little afraid to use it though. I can see a Tapestry pattern evolving from that that yields (String... stuff) as your parameter to your onActivate with a boatload of extravagant logic. Anyway, still haven't heard a useful suggestion to get objects into a "request only" scope. If anyone can think of something please post! It would be interesting to see what some of these values are that can only be set inside an action request but must then span into a render request. Thanks, Joel -Original Message- From: [EMAIL PROTECTED] on behalf of Josh Canfield Sent: Fri 5/2/2008 6:31 PM To: Tapestry users Subject: Re: T5: Persistence pains I generally consider flash persistence as a way to get an object from the action request to the render request... If you're going to set it in the render request you should consider adding code that validates that your data and context match up. You could, for instance, also flash persist your id and check it against the id from the context. If they don't match then null your other properties. > While some may argue that this is "just poor design", what if the fields > I initialize varies by product? I'd get a "merging" of the two products > on the screen depending on what was persisted first. Storing these things in your component smells funny... but I don't know your app. If someone is coming to the page for the first time you want an empty object, if they are posting an update to the form then Tapestry is going to populate the values. If you are navigating within the page using pagelinks, but it's a form then I'd consider posting the form instead... Josh On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman <[EMAIL PROTECTED]> wrote: > Sure Howard. > > Quite simply, "the back button". When loading a page with an activation > context, say: > > http://myapp.com/editproduct/20 (where 20 is a product ID) > > I'll initialize some flash-persistable values on the page from the > Product whose ID is 20. > > Now if the user clicks on the Back button and goes to a link that reuses > the
Re: Client side validation and IE
T5 uses Prototype and Scriptaculous for client side validation/ajax stuff. Our experience with Prototype and Scriptaculous has not been that great, especially when it comes to upgrading versions. Is there any way to disable the use of those libraries and/or the use of a different library (JQuery?)? It seems like a very invasive decision for T5 to force the use of a javascript UI library and also perform client side validation using a specific UI paradigm. - Original Message - From: "Howard Lewis Ship" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Friday, March 21, 2008 6:23 PM Subject: Re: Client side validation and IE Hm. It worked last time I checked. I have trouble checking the IE stuff since I work on a Mac. It involves me firing up a virtual machine, etc. On Wed, Mar 19, 2008 at 10:47 PM, Dmitry S <[EMAIL PROTECTED]> wrote: Hi, I tried T5 (5.0.11) client side validation in Internet Explorer, and it seems that it not works in IE6 (I see POST in jetty log) and IE7 brings up an ugly Error popup window "Object does not support property or method" -- View this message in context: http://www.nabble.com/Client-side-validation-and-IE-tp16172230p16172230.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new features in 5.0.11
Funny - my experience has been the exact opposite. Building a general purpose framework on one's personal experience can have shortfalls. For example you state in your blog "I also think Tapestry's built-in rules for URLs are really strong and appealing; I simply don't see customizing the built-in rules to be a priority, or frankly, of any great value." I can tell you the URL scheme of Tapestry would not work at all for some of the apps I've built. - Original Message - From: "Howard Lewis Ship" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Friday, March 14, 2008 2:38 AM Subject: Re: new features in 5.0.11 It's nice that you think that. The reality is that almost every application I've worked on or consulted for had a subset of pages that needed to be protected via HTTPS and the remainder could operate via HTTP. On Thu, Mar 13, 2008 at 6:01 PM, kranga <[EMAIL PROTECTED]> wrote: Defining secure access via HTTPS is a high level architectural decision. Seldom is one going to want to do that by annotation. - Original Message - From: "Angelo Chen" <[EMAIL PROTECTED]> To: Sent: Thursday, March 13, 2008 10:07 AM Subject: t5: new features in 5.0.11 > > Hi, > > As usual I always like to look at new features of every release, here are > the one officially listed as new to the 5.0.11: > > 1. The @Cached annotation has been added to allowing the caching of method > results. > > Can't understand this, any use case to explain this? > > 2. Tapestry can now generate accessor methods for fields automatically via > the @Property annotation. > > This is a cool feature, saving a lot of code. > > 3. It is now possible to override the built-in display and edit blocks for > data types. > > What's this? > > 4. Tapestry now supports "Index" pages at the root or in sub-folders. > > nice feature. > > 5. Tapestry pages may now be secured for access only via HTTPS. > > good feature. > > 6. Added the FormFragment component to allow for forms that are mutable on > the client-side. In addition, the Form component may now update a Zone. > > good feature. > > a.c. > -- > View this message in context: > http://www.nabble.com/t5%3A-new-features-in-5.0.11-tp16025541p16025541.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new features in 5.0.11
Defining secure access via HTTPS is a high level architectural decision. Seldom is one going to want to do that by annotation. - Original Message - From: "Angelo Chen" <[EMAIL PROTECTED]> To: Sent: Thursday, March 13, 2008 10:07 AM Subject: t5: new features in 5.0.11 Hi, As usual I always like to look at new features of every release, here are the one officially listed as new to the 5.0.11: 1. The @Cached annotation has been added to allowing the caching of method results. Can't understand this, any use case to explain this? 2. Tapestry can now generate accessor methods for fields automatically via the @Property annotation. This is a cool feature, saving a lot of code. 3. It is now possible to override the built-in display and edit blocks for data types. What's this? 4. Tapestry now supports "Index" pages at the root or in sub-folders. nice feature. 5. Tapestry pages may now be secured for access only via HTTPS. good feature. 6. Added the FormFragment component to allow for forms that are mutable on the client-side. In addition, the Form component may now update a Zone. good feature. a.c. -- View this message in context: http://www.nabble.com/t5%3A-new-features-in-5.0.11-tp16025541p16025541.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5 direction - general purpose vs specialized?
I was testing t5 (5.0.7) and saw that the form component automatically throws bubble messages for validation. T5 also seems to utilize Scriptaculous for achieving this. So my question is - is Tapestry meant to be specialized or general purpose? All our clients dictate the look-n-feel of error messages and such and so the default bubble will never work for us. I'm surprised that such a UI specific decision is made by T5. How much work will it be to use a different scheme for display/presentation of error messages? How dependent is T5 going to be on Scriptaculous and how much tweaking will one have to do to circumvent its use? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Page from sub-package
Thanks for the input Kevin... The T5 documentation states: The dispatcher here strips terms off of the path until it finds a known page name. Thus, "/mypage/27" would look first for a page whose name was "mypage/27", then look for a page name "mypage". Assuming the second search was succesful, the page would be activated with the context "27". So obviously it is not working per the spec. - I remember running into that before. I spent some time trying to figure it out before deciding to just restructure my pages. The issue, as near as I can tell, is that Tapestry cannot distinguish between activation context and pages. Or rather, a preference is given to the former over the latter. My opinion, it should be the other way around, and thinking about it now, may not actually require that much of a change to the T5 code. -- Kevin On 1/22/08 7:15 AM, in article [EMAIL PROTECTED], "kranga" <[EMAIL PROTECTED]> wrote: > I'm using 5.0.7 > > I have a page called Admin.java in the root "pages" package. I also have a > page called Search.java in package "pages/admin/" > When I send a request to /admin, Tapestry correctly renders the admin page. > But when I send a request to /admin/search, I still get the admin page. How > do I get the Search.java page to be invoked? > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5: Page from sub-package
I'm using 5.0.7 I have a page called Admin.java in the root "pages" package. I also have a page called Search.java in package "pages/admin/" When I send a request to /admin, Tapestry correctly renders the admin page. But when I send a request to /admin/search, I still get the admin page. How do I get the Search.java page to be invoked? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Roadmap
I didn't implicate you as stupid. You wouldn't be using Tapestry if you were stupid. I was commenting on you summarily dismissing the concerns of quite a few Tapestry users about the lack of version compatiblity and your implying that this was the industry norm. Look, Howard has carte blanche on what he wants to do or not do with Tapestry. He states that T5 is laying the foundation for future compatiblity. So be it. All I can say is that in a few years when there is the "next new thing" out there and T5 cannot support it, he may yet again abandon backwards compatiblity. If he does, again, he has carte blanche. But, you cannot claim that the lack of backward compatiblity is a non-issue. That is a slap in the face of corporations and consultants like me who pushed to get T3/T4 adopted and now look not so good because the corporation is faced with finding developers who can code to an outdated framework and where the upgrade path is steep. But that is open source and life. Just don't call it "normal business practice in the marketplace." I didn't and never meant to insult anyone personally. No ad hominim attacks .. - Original Message - From: "Christian Gruber" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Tuesday, October 23, 2007 11:32 AM Subject: Re: Tapestry 5 Roadmap Ok, whatever. I give in. I'll go and use T4 and whine at Howard now. Oh wait, no I won't. I'll work on T5 and try to encourage it into as re-usable, and less brittle and change-vulnerable a form as I can, so that there is more likelihood of upgradability. (Howard's doing quite well about that already) Honestly, I wouldn't be so hostile at the moment if Kranga hadn't dropped the implication that I was stupid for merely observing something about version numbers. Just follow the links. I'm not saying anyone's wrong for saying that they want compatibility. I'm just saying (and it was all I was saying) that often (and provably often - see the links) major version numbers indicate incompatibility. That's not my opinion - that's an observation. I wasn't saying it was right, or better. I'm saying it's fair of the author to do what other software has clearly done before him, and Howard had the decency to make a major version bump to indicate that it's a new platform. I suppose he could have called it TapestryNG or something. Anyway, I'm out of this conversation. When people are comparing opinion with observed (and referenced) facts and giving me grief for it, they should try editing Wikipedia more. There at least that kind of thing isn't tolerated. Christian. On 23-Oct-07, at 9:15 AM, Peter Stavrinides wrote: Christian, kranga is right. You can't keep telling yourself it is okay to change the framework to the point that an entire rewrite is needed to existing code. Some upgrading is expected (and necessary), but Tapestry will die a quick death, no matter how good it is under the hood, if you slap devotees in the face again and again. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Roadmap
I am speaking from my experience (and based on others in the mailing list who have echoed a similar sentiment). It is very frustrating for an organization to decide to use a framework and then find it is "legacy" in 6 months. Such is software development (and open source) and developers and corporations take that into account when putting their resources in. This shows in the lack of Tapestry adoption. And btw native database apis don't change. Oracle for e.g. has a huge backward compatiblity legacy. There are changes in most software, but not a complete rewrite. - Original Message - From: "Christian Gruber" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Friday, October 19, 2007 11:52 AM Subject: Re: Tapestry 5 Roadmap Egregious? That demands and answer and perhaps an apology. Firstly, try porting and app from Weblogic Portal 8 to Weblogic Portal 9. It has conversion tools, but it's not compatible without up- conversion. Upconversion doesn't count. Then think of eclipse and the plugins geared for such. As to appservers themselves, core platforms have a higher bar for backwards compatibility and always have than component frameworks. Databases are also externally compatible only because they conform to an API they didn't write themselves (SQL92, etc.). I'm not sure about MySQL, but many SQL databases that have native APIs are not API compatible between releases when using that native API. And try to move the files over between databases, and you have to do an export and an import, because you can't just install an upgrade and have everything work. As I said, upconversion doesn't count. We're talking about a component framework, which is highly finicky. If you update the major versions, it's not unreasonable that existing components won't work. I mean Howard could have spent a lot of effort making a bridge or translation system to maintain compatibility (which is often how total rewrites gain their backwards compatibility... see windows), but he didn't (clearly) think that was worth his time. Of course, it's open-source, so you could do it, if you wanted it badly enough. Oh, and blah blah blah fork blah blah. You know that part. Regardless of all of this, at least one major apache project has this policy too, and that's from 2 minutes on google.http://apr.apache.org/versioning.html . Major versions mean incompatible releases. That's (in my experience, except for platforms themselves) often the (non-marketing) meaning of major versions. A few other examples: http://www.jmock.org/versioning.html http://xstream.codehaus.org/versioning.html http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html http://wiki.eclipse.org/Version_Numbering ... oh, and most unix libraries. While not absolutely true in all cases, it is most certainly true in many cases, and is not unreasonable. Now apologize for your imputation, sir, for you are substantially, demonstrably incorrect. Christian. P.S. Ok, I'm not really that offended, just irritated with how personal you just made it. I don't like being called out for simple observations from 15 years in software development. On 19-Oct-07, at 7:00 AM, kranga wrote: That is an incredible statement! There have been numerous discussions on this mailing list on the way T4 was made completely incompatible since it was going to incorporate the very best and then T5 was made even more incompatible to incorporate the latest. This has been a vexing issue with quite a few people and organizations who invested in T3/T4 based projects. By way of example, tell me how these products are not compatible within major releases: Websphere 4, 5, 6 WebLogic: 8, 9, 10 MySQL: 4, 5 Hibernate: 2, 3 There are some pieces that change and new features are introduced. But your don't have to do a major rewrite to use the newer version. As an example, if T5 were T4 + annotations, that would be a compatible release. But Howard has chosen to rewrite it from the ground up with no compatiblity concern. Well, thats his prerogative as this is open-source community driven development. If I want, I can take the T3 code base and establish my own framework. However, it also reflects on the popularly or lack of for Tapestry. This topic has been beaten to death and I don't wish to bring it up again. However, your point regarding versions was egregious. - Original Message - From: "Christian Gruber" <[EMAIL PROTECTED] > To: "Tapestry users" Sent: Thursday, October 18, 2007 10:58 AM Subject: Re: Tapestry 5 Roadmap I'm not sure where "incompatible releases" comes in. No one releases 1.0 -> 2.0 compatible releases except O/S vendors. That's typically what the larg
Re: Tapestry 5 Roadmap
That is an incredible statement! There have been numerous discussions on this mailing list on the way T4 was made completely incompatible since it was going to incorporate the very best and then T5 was made even more incompatible to incorporate the latest. This has been a vexing issue with quite a few people and organizations who invested in T3/T4 based projects. By way of example, tell me how these products are not compatible within major releases: Websphere 4, 5, 6 WebLogic: 8, 9, 10 MySQL: 4, 5 Hibernate: 2, 3 There are some pieces that change and new features are introduced. But your don't have to do a major rewrite to use the newer version. As an example, if T5 were T4 + annotations, that would be a compatible release. But Howard has chosen to rewrite it from the ground up with no compatiblity concern. Well, thats his prerogative as this is open-source community driven development. If I want, I can take the T3 code base and establish my own framework. However, it also reflects on the popularly or lack of for Tapestry. This topic has been beaten to death and I don't wish to bring it up again. However, your point regarding versions was egregious. - Original Message - From: "Christian Gruber" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Thursday, October 18, 2007 10:58 AM Subject: Re: Tapestry 5 Roadmap I'm not sure where "incompatible releases" comes in. No one releases 1.0 -> 2.0 compatible releases except O/S vendors. That's typically what the large version number change means - these are incompatible. That's not a strike against Tapestry, that's an industry expectation. Christian On 18-Oct-07, at 6:45 AM, kranga wrote: The question is very relevant. The concern of the project should be to build out the business functionality using existing tools. If the tools in question are not yet released and in production, there is a very legitimate concern that the maintenance of the tool will become a partial focus. Tapestry may be a compelling offering technologically, but it has many other factors going against it - lack of a developer mindshare, incompatible releases in the past, etc. We have used Tapestry for big projects - but we are still using T3 since T4 and T5 are completely incompatible. You cannot push beta software past project stakeholders unless that beta software is also providing you with competitive advantage. T5 has some able competitors in Wicket and JSF/Stripes, etc while still lacking an ajax foundation for instance. So the competitive advantage is not clear cut. - Original Message - From: "Alex Shneyderman" <[EMAIL PROTECTED] > To: "Tapestry users" Sent: Thursday, October 18, 2007 3:22 AM Subject: Re: Tapestry 5 Roadmap The one question I could not answer without looking ridiculous was "What happens to our multi-million dollar project if Howard is hit by a bus tomorrow" I think the question is irrelevant. The question you should be answering: Is the current base usable enough to push through on the project?. A relevant after-question (if answer to the above is not exactly) to answer how easy it is to add the features you are missing if you have to. And how easy it is to poke through the tapestry's source-base to fix bugs that might exist and you will find during the project's development. If you can cross off HLS as your dependency then t5 is probably the best choice to make from what's available out there :-) Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Roadmap
The question is very relevant. The concern of the project should be to build out the business functionality using existing tools. If the tools in question are not yet released and in production, there is a very legitimate concern that the maintenance of the tool will become a partial focus. Tapestry may be a compelling offering technologically, but it has many other factors going against it - lack of a developer mindshare, incompatible releases in the past, etc. We have used Tapestry for big projects - but we are still using T3 since T4 and T5 are completely incompatible. You cannot push beta software past project stakeholders unless that beta software is also providing you with competitive advantage. T5 has some able competitors in Wicket and JSF/Stripes, etc while still lacking an ajax foundation for instance. So the competitive advantage is not clear cut. - Original Message - From: "Alex Shneyderman" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Thursday, October 18, 2007 3:22 AM Subject: Re: Tapestry 5 Roadmap The one question I could not answer without looking ridiculous was "What happens to our multi-million dollar project if Howard is hit by a bus tomorrow" I think the question is irrelevant. The question you should be answering: Is the current base usable enough to push through on the project?. A relevant after-question (if answer to the above is not exactly) to answer how easy it is to add the features you are missing if you have to. And how easy it is to poke through the tapestry's source-base to fix bugs that might exist and you will find during the project's development. If you can cross off HLS as your dependency then t5 is probably the best choice to make from what's available out there :-) Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Roadmap
Actually, this is one advantage of Tapestry: guaranteed quality. That flies in the face of the philosophy of open source ... - Original Message - From: "Yunhua Sang" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Wednesday, October 17, 2007 11:09 AM Subject: Re: Tapestry 5 Roadmap 2. Tapestry is an one man show. .. Actually, this is one advantage of Tapestry: guaranteed quality. On 10/17/07, Daniel Jue <[EMAIL PROTECTED]> wrote: > "What > happens to our multi-million dollar project if Howard is hit by a bus > tomorrow" Yes, please don't do that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5 Release date?
Is there a new roadmap for the release of T5? The website says Fall 2007 and includes a note that the release has slipped ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparison
We've been using serialize + gzip + base64 encode using T3 for a couple of years - never had an issue with performance at all ... - Original Message - From: "Howard Lewis Ship" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Thursday, September 27, 2007 7:03 PM Subject: Re: Comparison An ASO is an application state object. ASOs are created on demand, and shared between pages. ASOs are generally stored in the HttpSession. A client ASO would be all that, but would be stored on the client (inside hidden form fields or query parameters). This has some costs: serializing the objects, and the question of security. On 9/27/07, Anton Gavazuk <[EMAIL PROTECTED]> wrote: Sorry for interruption :) - what is Client-side ASO? 2007/9/27, Howard Lewis Ship <[EMAIL PROTECTED]>: > > Client-side page persistence is in there, I'l have to check if it is > documented. Client-side ASOs are not there yet (and there is not yet a > JIRA > issue to implement them). > > On 9/27/07, kranga <[EMAIL PROTECTED]> wrote: > > > > The one feature that T5 is missing and keeps us in T3 is lack of support > > for > > client-side session persistence. With the redirect-after-submit paradigm > > ingrained in T5 (a design decision I think a framework shouldn't be > > making), > > I can't have state hidden in forms persisted through the redirect and > > hence > > am forced to use the session. > > > > - Original Message - > > From: "Francois Armand" <[EMAIL PROTECTED]> > > To: "Tapestry users" > > Sent: Thursday, September 27, 2007 4:24 AM > > Subject: Re: Comparison > > > > > > > Christian Gorbach wrote: > > >> Here's a recent comparison of Wicket and Tap from Ken Tong: > > >> > > http://agileskills2.org/blog/2007/09/my_thoughts_on_the_differences.html > > >> cheers > > >> c)hristian > > >> > > > (I'm sorry, I would have answer on your blog, but it seems that > > something > > > does not work with typekey login, I get a error message : "The site > > you're > > > trying to comment on has not signed up for this feature. Please inform > > the > > > site owner.") > > > > > > Well, I mostly agree with the major part of your post, except for the > > ease > > > of use : a few month ago, I has to choose a new web framework and > tested > > > wicket (1.3, first betas) and Tapestry 5. And I found Tapestry 5 far > > > simpler to understand and use than Wicket, with no possible comparison > ! > > > > > > So, perhaps previous version of Tapestry used to be hard, but Tapestry > 5 > > > is just the simplest Java web framework that I ever used (note: this > > > assertion really depends of my personal background, the fact that I > > never > > > code any line of Swing but I know Spring/IoC for a long time, and that > I > > > only spend some time with Struts, Struts 2, Stripes, Wicket and > Tapestry > > > 5). > > > > > > Really, Tapestry 5 has a lot of default, the bigger one being that > it's > > > still alpha, but it *is* simple. Being productive with it is a matter > > of > > > minutes... > > > > > > > > > -- > > > Francois Armand > > > Etudes & Développements J2EE > > > Groupe Linagora - http://www.linagora.com > > > Tél.: +33 (0)1 58 18 68 28 > > > --- > > > InterLDAP - http://interldap.org FederID - http://www.federid.org/ > > > Open Source identities management and federation > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Howard M. Lewis Ship > Partner and Senior Architect at Feature50 > > Creator Apache Tapestry and Apache HiveMind > -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparison
The one feature that T5 is missing and keeps us in T3 is lack of support for client-side session persistence. With the redirect-after-submit paradigm ingrained in T5 (a design decision I think a framework shouldn't be making), I can't have state hidden in forms persisted through the redirect and hence am forced to use the session. - Original Message - From: "Francois Armand" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Thursday, September 27, 2007 4:24 AM Subject: Re: Comparison Christian Gorbach wrote: Here's a recent comparison of Wicket and Tap from Ken Tong: http://agileskills2.org/blog/2007/09/my_thoughts_on_the_differences.html cheers c)hristian (I'm sorry, I would have answer on your blog, but it seems that something does not work with typekey login, I get a error message : "The site you're trying to comment on has not signed up for this feature. Please inform the site owner.") Well, I mostly agree with the major part of your post, except for the ease of use : a few month ago, I has to choose a new web framework and tested wicket (1.3, first betas) and Tapestry 5. And I found Tapestry 5 far simpler to understand and use than Wicket, with no possible comparison ! So, perhaps previous version of Tapestry used to be hard, but Tapestry 5 is just the simplest Java web framework that I ever used (note: this assertion really depends of my personal background, the fact that I never code any line of Swing but I know Spring/IoC for a long time, and that I only spend some time with Struts, Struts 2, Stripes, Wicket and Tapestry 5). Really, Tapestry 5 has a lot of default, the bigger one being that it's still alpha, but it *is* simple. Being productive with it is a matter of minutes... -- Francois Armand Etudes & Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparison
Someone correct me if I'm wrong - but I believe GWT is designed for "single page" applications - aka swing style where additional UI screens are dialogs/panels etc. I think the size of your javascript will rapidly increase as you try to stuff more pieces that should be standalone pages into panels within a single page. - Original Message - From: "Borut Bolčina" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Thursday, September 27, 2007 5:29 AM Subject: Re: Comparison Thanks for your input Francois. Nobody has mentioned GWT so far. Is it an enterprise player at all? There are posts on the web and seminars on how to build large web apps with GWT. How does the dev cycle between developer and designer look like with GWT? -Borut 2007/9/25, Francois Armand <[EMAIL PROTECTED]>: Borut Bolčina wrote: > Hello, > > has anyone done a fair comparison of T5, JSF (any incarnation), Wicket > or/and any other Java web framework. I > Well, realy broad question. You should find some ideas here : http://raibledesigns.com/rd/entry/choosing_a_jvm_web_framework1 and all around the web. Of course, the subject is highly trollistic. > Can you please expose strengths and weaknesses of T5 and other players in > enterprise environment. Just drop a plus and minus for one or two features. > In my point of view, really bascaly, I would say : * Struts 2 / Spring MVC / Stripe : nice MVC, "classic" java framework. Far better than Struts, but *I* don't like the way they work. More "component / event oriented" : * JSF : after EJB 2, the new over-engineered Sun tech ... Well, Seam seems to be the best approach to JSF. The big plus : it's a JSR, so eventually, it shall be supported/known by a lots of people. * Wicket : the "web is like Swing" approach is interesting. Some friends of mine love it, but something with the "statefull by default" behaviour dislike me (I never did Swing development, perhaps it's a reason) * Tapestry 5 : really simple and nice, I like the IoC (but I was doing Spring/Guice development for almost 6 month before discovering T5), the ease of doing new component. The big minus are : it's still alpha (and so it lacks polish, AJAX, basic components, etc), it lacks a big community/visibility, the migration path between major version is quite frightening (but it should be better from now). Of course, it's my biased opinion. After all, I wouldn't use T5 if I dislike it. -- Francois Armand Etudes & Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Comment about Tapestry's growth
http://www.javalobby.org/java/forums/t101110.html Tapestry, despite being a strong competitor to JSF, has gone virtually no where. once it is experienced its initial growth spurt after being released. It's basically flat. Unlike the Ruby on Rails vs. Spring data, the data at dice.com seems to support this one. There are currently only 87 jobs listed for Tapestry. This part is hard to debate no matter how you spin the numbers. Tapestry is virtually flat as far as having any kind of growth. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Redirect after form submit - concerns
If T5 already has the ability to persist fields into a form, then how to do you retain those fields during a redirect? The URL is not long enough to serialize every hidden field. So you'd be forced to store it in the session, which breaks the scenario of multiple browser windows in the same session. - Original Message - From: "Howard Lewis Ship" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Monday, July 09, 2007 10:06 AM Subject: Re: T5: Redirect after form submit - concerns T5 has the ability to to persist field properties onto the client (as zipped/based64) automatically. These show up as hidden form fields or extra query parameters. Not implemented yet is the ability to "scope" the data to only hidden form fields (but leave normal links unchanged) ... the API is present, there just isn't an implementation yet. On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: We are in the process of evaluating T5 and other frameworks to upgrade our existing trading applications from T3. We extensively use objects serialized to hidden fields (zipped and base64 encoded) to manage state because we absolutely have to support multiple browser windows in the same session. However, T5's redirect after form submit throws a wrench in the design since it forces the uses of session to store the data which fails with multiple browsers and creates unnecessary traffic in a clustered deployment. Why is this redirect necessary and is there a way of overriding/turning it off? If there is no way around it, T5 will not be an option for us to upgrade to. So I'm hoping to arrive at a solution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5: Redirect after form submit - concerns
We are in the process of evaluating T5 and other frameworks to upgrade our existing trading applications from T3. We extensively use objects serialized to hidden fields (zipped and base64 encoded) to manage state because we absolutely have to support multiple browser windows in the same session. However, T5's redirect after form submit throws a wrench in the design since it forces the uses of session to store the data which fails with multiple browsers and creates unnecessary traffic in a clustered deployment. Why is this redirect necessary and is there a way of overriding/turning it off? If there is no way around it, T5 will not be an option for us to upgrade to. So I'm hoping to arrive at a solution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5: Feature request
Hi Tapestry developers:
Is it possible to add friendly/custom URL support using annotations? If
I mark my page class with an annotation such as @URL("/a/b/c/foo"), then
Tapestry can internally automatically generate a filter that maps the URL to
my page class. So a request such as /a/b/c/foo?id=1 can be handled by the
appropriate class (in this case setting a field called id to 1). Is this
possible?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: New Validators and server side validation
We just introduced client side validation for Tapestry fields using an ajax
call back to the server side (with Tapestry 3). So you only write Java code
for the validation and the same code gets called from the client side. All
parameters for controlling your validation are automatically sent back as
part of the ajax call and you can define when the check is triggered (e.g.
onBlur) and which one of the "error marker" components tied to the input
field will show the errors. Makes the code very clean and the front-end
experience is slick (e.g. registration page has the same validator to check
if username is taken and this is fired from the client and from the
server!). I'd suggest T5 move to such a design.
- Original Message -
From: "Bill Holloway" <[EMAIL PROTECTED]>
To: "Tapestry users"
Sent: Wednesday, May 16, 2007 2:27 PM
Subject: Re: T5: New Validators and server side validation
That's got it, Ben. Thanks. Wish I knew more about javascript
prototyping. Too much technology to stay familiar with.
Bill
On 5/16/07, Ben Sommerville <[EMAIL PROTECTED]> wrote:
Bill,
This
> pageRenderSupport.addScript(
> "Tapestry.Field.email('%s', %s);",
> field.getClientId(),
> quote(buildMessage(formatter, field)));
does not construct a function validating emails. What it is doing is
inserting
a function call to register a particular field for validation.
On the page sent to the client you would get something like
That is the source of your error message, the Tapestry.Field.email
function
does not exist but you are trying to call it.
What you need to do is define the email validation function yourself in a
javascript file. I would add it to a different namespace so that it is
clear
it is not a standard Tapestry function.
e.g. in myproject-valdation.js
var MyProject = {};
MyProject.Field = {
email: function(field, message) {
Tapestry.addValidator(field, false, function(value, event) {
if( X ) {
event.recordError(message)
}
});
}
}
where is the javascript to test if "value" is a valid email address.
Add a script include to your border/page (to load your validation
function)
and change the render method to use MyProject.Field.email and you are
good
to go
cheers.
--
Ben Sommerville
> -Original Message-
> From: Bill Holloway [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 16 May 2007 4:33 PM
> To: Tapestry users
> Subject: Re: T5: New Validators and server side validation
>
> In implementing an e-mail validator myself, one thing I notice in all
> this is a Javascript error that reads
>
> Error: Tapestry.Field.email is not a function...
>
> I did some digging and found in org/apache/tapestry/tapestry.js the
> building up of the Tapestry object has in it a section involving
> "Collection of field based functions related to validation." In that
> part of the object prototyping (I guess), each of the built-in
> validation types (required, minlength, maxlength, min, and max) has a
> function assigned that, essentially, duplicates the functionality of
> the Java-based validators. All that prototyping must be for the
> client-side functionality.
>
> So I'm wondering why my AppModule-provided EmailValidator class'
> render() method isn't contributing the script. Its code is
>
> pageRenderSupport.addScript(
> "Tapestry.Field.email('%s', %s);",
> field.getClientId(),
> quote(buildMessage(formatter, field)));
>
> Since I implementing something for render(), I would think that at
> least some kind of function for Tapestry.Field.email would show up
> (even if it has the wrong number of fields, etc), knocking out the
> "...is not a function" error.
>
> Bill
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
"The future is here. It's just not evenly distributed yet."
-- Traditional
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Redirects
Why do you need numbers to understand that an extra redirect adds to rendering delay? On storing values in session, why should I be forced to use a "flash" technology to handle session. A framework that attempts to be non-intrusive shouldn't force a session storage strategy because of the way it handles links! Doing a redirect on every link request is a very intrusive idea. I hope the Tap developers will re-evaluate this decision in light of the intrusiveness. As an example, lets say someone wanted to build ajax functionality on top of this link request. Every ajax request would be returned as a redirect response. Doesn't sound good. A framework forcing you to do something because thats how it works - well, that sounds like something Tap 5 was aiming to avoid. Or am I wrong on that? - Original Message - From: "Massimo Lusetti" <[EMAIL PROTECTED]> To: "Tapestry users" <[EMAIL PROTECTED]> Sent: Friday, April 13, 2007 11:04 AM Subject: Re: Tapestry 5 Redirects On 4/13/07, kranga <[EMAIL PROTECTED]> wrote: 1) Log analysis: Your page hit statistics and other log based audit and troubleshooting activity need to take this into account. All requests fall in to logs, anyway logs are configurable server entities and are by no means related to application scope. 2) Extra unwanted delay and traffic in rendering pages. Do you have numbers? Storing page state in the session in general is a bad idea. When you have multiple browser windows connected to the same session, you have complete chaos. Someone has already answered your question in this thread. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Redirects
Reasons I can think of: 1) Log analysis: Your page hit statistics and other log based audit and troubleshooting activity need to take this into account. 2) Extra unwanted delay and traffic in rendering pages. Storing page state in the session in general is a bad idea. When you have multiple browser windows connected to the same session, you have complete chaos. - Original Message - From: "Patrick Moore" <[EMAIL PROTECTED]> To: "Tapestry users" <[EMAIL PROTECTED]> Sent: Friday, April 13, 2007 12:59 AM Subject: Re: Tapestry 5 Redirects well at least one reason is that phone browsers ask the user to confirm each and every client-side redirect On 4/12/07, Massimo Lusetti <[EMAIL PROTECTED]> wrote: On 4/12/07, Andreas Pardeike <[EMAIL PROTECTED]> wrote: > Is that clever design? I can think of several reasons why this could be > a bad idea. What's the reasoning behind this? Redirects helps you keeping your url and page states cleans, i mean helps you a lot. Which use case do you think to address? -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 vs T4 vs Community
Well, I hope you are earnest in that objective moving forward. At the end of the day I am not questioning the technological marvel that Tapestry is. Otherwise I wouldn't be using it. But I feel like quite a few of us who have championed the use of Tapestry within our organizations have been let down. Hopefully T5 and beyond will work to build a user base. - Original Message - From: "Howard Lewis Ship" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Saturday, March 31, 2007 3:33 PM Subject: Re: T5 vs T4 vs Community The difference is that I'm designing everything in T5 to support that goal (a clean separation to support easy upgrades). This wasn't a goal in T1 to T4 ... chalk it up to experience. On 3/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: You said: "I guess there will be two questions to ask when the time comes: What is the best framework? Are there likely to be sweeping changes after T5? I'm inclined to agree with HLS that after T5, it should be possible to make changes under the hood without breaking existing code." I don't know on what basis you are making this conclusion. The only facts that I have to go by are: 1) Past performance: Changes between T3, T4 and T5 2) Pace of technology change 3) Stated objectives/design principles/priorities by Tap devs. "it should be possible to make changes under the hood without breaking existing code" => I've been around long enough to know how that works! --- I can see your points, but I disagree. With regard to the dramatic changes between 4.x and 5, I think it is worth it to go through short-term pain for long-term gain. I have seriously questioned my choice of Tapestry because of these changes but keep coming up with, "Wow, this is how it should be done!" If I look at the applications I've done in 4.0.x, I have good separation between the layers. I have investments in the CSS, and the HTML that will largely be retained, as well as all of the services, security and persistence infrastructure. I will probably go from 4.0.2 to 5.0.x because I currently don't need the AJAX functionality, though I would certainly go to 4.1.x if a project comes up where I need it. Maybe JSF is where your future lies. If I were you, since there seems to be no serious time-pressure, I would look at your T3 applications and think about preparing for a move. Start refactoring now to ensure good separation that will help you regardless of what you pick as your T3 successor. I guess there will be two questions to ask when the time comes: What is the best framework? Are there likely to be sweeping changes after T5? I'm inclined to agree with HLS that after T5, it should be possible to make changes under the hood without breaking existing code. IMHO Jonathan > -Original Message- > From: kranga [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 31, 2007 9:23 AM > To: Tapestry users > Subject: Re: T5 vs T4 vs Community > > We invested in T3 and are sticking with it until JSF matures some more > (with > Infragistics releasing their component base for JSF, thats a great > boost). > Clearly the Tapestry developers are in the pursuit of new > features/technologies rather than building up a community. Not that > there > is > anything wrong with that, it is just their priority. However, the > consequence is reflected in the "niche and esoteric" nature of Tapestry > with > a glaring lack of widespread use. Tapestry gives you no lock-in and for > every upgrade you think of, you are given the opportunity to evaluate > any > other framework out there :) > > - Original Message - > From: "Martino Piccinato" <[EMAIL PROTECTED]> > To: "Tapestry users" > Sent: Thursday, March 29, 2007 10:39 AM > Subject: Re: T5 vs T4 vs Community > > > > Well, I know it's not T4 => T5, I was just adding a possible source > > of > bad > > perception due to this misconception (and to misnaming...?) > > > > I think that the fact of not having a stable T4 "ajax ready" release > > add > > confusion to this. A customer thinking that T4 => T5 might think > > "well > > they > > are not pushing that much on T4 with ajax because they are already > working > > on T5, so as I want to work with Ajax why should I work with T4 that > will > > be > > soon outdated and not retrocompatible with T5?". And so on... > > > > > > > > > > And actually having > > > > On 3/29/07, Andrea Chiumenti <[EMAIL PROTECTED]> wrote: > >> > >> Martino, > >> your comment is because you consider T4=>T5 as the major part of >
RE: T5 vs T4 vs Community
You said: "I guess there will be two questions to ask when the time comes: What is the best framework? Are there likely to be sweeping changes after T5? I'm inclined to agree with HLS that after T5, it should be possible to make changes under the hood without breaking existing code." I don't know on what basis you are making this conclusion. The only facts that I have to go by are: 1) Past performance: Changes between T3, T4 and T5 2) Pace of technology change 3) Stated objectives/design principles/priorities by Tap devs. "it should be possible to make changes under the hood without breaking existing code" => I've been around long enough to know how that works! --- I can see your points, but I disagree. With regard to the dramatic changes between 4.x and 5, I think it is worth it to go through short-term pain for long-term gain. I have seriously questioned my choice of Tapestry because of these changes but keep coming up with, "Wow, this is how it should be done!" If I look at the applications I've done in 4.0.x, I have good separation between the layers. I have investments in the CSS, and the HTML that will largely be retained, as well as all of the services, security and persistence infrastructure. I will probably go from 4.0.2 to 5.0.x because I currently don't need the AJAX functionality, though I would certainly go to 4.1.x if a project comes up where I need it. Maybe JSF is where your future lies. If I were you, since there seems to be no serious time-pressure, I would look at your T3 applications and think about preparing for a move. Start refactoring now to ensure good separation that will help you regardless of what you pick as your T3 successor. I guess there will be two questions to ask when the time comes: What is the best framework? Are there likely to be sweeping changes after T5? I'm inclined to agree with HLS that after T5, it should be possible to make changes under the hood without breaking existing code. IMHO Jonathan > -Original Message- > From: kranga [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 31, 2007 9:23 AM > To: Tapestry users > Subject: Re: T5 vs T4 vs Community > > We invested in T3 and are sticking with it until JSF matures some more > (with > Infragistics releasing their component base for JSF, thats a great boost). > Clearly the Tapestry developers are in the pursuit of new > features/technologies rather than building up a community. Not that there > is > anything wrong with that, it is just their priority. However, the > consequence is reflected in the "niche and esoteric" nature of Tapestry > with > a glaring lack of widespread use. Tapestry gives you no lock-in and for > every upgrade you think of, you are given the opportunity to evaluate any > other framework out there :) > > - Original Message - > From: "Martino Piccinato" <[EMAIL PROTECTED]> > To: "Tapestry users" > Sent: Thursday, March 29, 2007 10:39 AM > Subject: Re: T5 vs T4 vs Community > > > > Well, I know it's not T4 => T5, I was just adding a possible source of > bad > > perception due to this misconception (and to misnaming...?) > > > > I think that the fact of not having a stable T4 "ajax ready" release add > > confusion to this. A customer thinking that T4 => T5 might think "well > > they > > are not pushing that much on T4 with ajax because they are already > working > > on T5, so as I want to work with Ajax why should I work with T4 that > will > > be > > soon outdated and not retrocompatible with T5?". And so on... > > > > > > > > > > And actually having > > > > On 3/29/07, Andrea Chiumenti <[EMAIL PROTECTED]> wrote: > >> > >> Martino, > >> your comment is because you consider T4=>T5 as the major part of people > >> does. > >> > >> On 3/29/07, Martino Piccinato <[EMAIL PROTECTED]> wrote: > >> > > >> > I think another bad perception might origin from the fact of having > the > >> T4 > >> > "Ajax ready" 4.1 release still not released as stable after quite a > >> > long > >> > time and a completely new not retrocompatible T5 appear (the same to > >> > me: > >> > not > >> > critiques, just observations). > >> > > >> > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 vs T4 vs Community
We invested in T3 and are sticking with it until JSF matures some more (with Infragistics releasing their component base for JSF, thats a great boost). Clearly the Tapestry developers are in the pursuit of new features/technologies rather than building up a community. Not that there is anything wrong with that, it is just their priority. However, the consequence is reflected in the "niche and esoteric" nature of Tapestry with a glaring lack of widespread use. Tapestry gives you no lock-in and for every upgrade you think of, you are given the opportunity to evaluate any other framework out there :) - Original Message - From: "Martino Piccinato" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Thursday, March 29, 2007 10:39 AM Subject: Re: T5 vs T4 vs Community Well, I know it's not T4 => T5, I was just adding a possible source of bad perception due to this misconception (and to misnaming...?) I think that the fact of not having a stable T4 "ajax ready" release add confusion to this. A customer thinking that T4 => T5 might think "well they are not pushing that much on T4 with ajax because they are already working on T5, so as I want to work with Ajax why should I work with T4 that will be soon outdated and not retrocompatible with T5?". And so on... And actually having On 3/29/07, Andrea Chiumenti <[EMAIL PROTECTED]> wrote: Martino, your comment is because you consider T4=>T5 as the major part of people does. On 3/29/07, Martino Piccinato <[EMAIL PROTECTED]> wrote: > > I think another bad perception might origin from the fact of having the T4 > "Ajax ready" 4.1 release still not released as stable after quite a > long > time and a completely new not retrocompatible T5 appear (the same to > me: > not > critiques, just observations). > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TapIDEA future, post "Time to move on"
While one can disagree about the actual productivity increase offered by an
IDE plugin, you can't deny that it is a major plus for new adoptions. That
said, I think Tapestry is in a unique situation with the incompatibility
between T3, 4 and 5. We've developed some large applications using T3 and
given the direction Tap is heading in, are definitely going to evaluate
other frameworks when we think of upgrading (high barrier to upgrade implies
lower barrier to exit the platform). As it is, I have no incentive to adopt
T4 when T5 is going to be different. By the time T5 matures, there will be
several other frameworks (including Wicket, Echo2 and perhaps even .NET 2.0)
that will be exciting alternatives. At the end of the day, even though I am
a technologist at heart, technology exists because of business and
businesses don't care about how "cool" your internal architecture is, they
care about not spending millions to just upgrade to the latest without a
proportional increase in business functionality or decrease in cost of
operations neither of which are the case here IMHO.
Now before you respond, please note this is my personal experience. I'm sure
others will beg to disagree. I am making this post for those in a similar
situation aware of this being a shared experience (I know people have posted
of how they vouched for Tapestry only to look not so favorable a few years
down the road). With the current trend future compatibility will always be
broken because there will always be the next great thing and so the
temptation to make T6 incompatible. T3 for all its worth gives me enough so
I can weigh options and evaluate trends with leisure.
T3: Judgement day!
- Original Message -
From: "andyhot" <[EMAIL PROTECTED]>
To: "Tapestry users"
Sent: Tuesday, August 29, 2006 8:10 PM
Subject: Re: TapIDEA future, post "Time to move on"
spindle-core (for Tap4) does this way in an IDE independent way.
I was taking a look at it 4 months ago, and I was able to do exactly this.
For instance:
public static void main(String[] args) {
TapestryCore core = new TapestryCore(new TestLogger(),
new LocalCoreListeners(), new LocalPreferenceSource());
ITapestryProject project = new LocalProject();
LocalBuild build = new LocalBuild(project);
build.build(false, new HashMap());
System.out.println(build.problemPersister);
}
All Local* classes where my implementations for the IDE-agnostic
interfaces
that spindle-core provides.
When i first tried it, it did output a few non errors (i think it didn't
understand default-value)
so I don't know what (other) errors currently exist.
I can give the latest version a try in a big project and see how it goes.
Konstantin Ignatyev wrote:
Agreed, but that could be done as build time 'check'
step. Something like JSP compiler task
http://ant.apache.org/manual/OptionalTasks/jspc.html
I think it could be easier to create than full IDE
plugin and such core service might be a very good
foundation for people willing to build IDE specific UI
layer atop of it.
--- D&J Gredler <[EMAIL PROTECTED]> wrote:
I mostly agree with you that current tooling gets us
pretty far, but there's
a lot to be said for turning the most frequent
"runtime" errors into
"compile-time" errors, something that often requires
special Tapestry
awareness.
On 8/29/06, Konstantin Ignatyev
<[EMAIL PROTECTED]> wrote:
My point is that in case of Tapestry/Wicket there
is
no need to worry much about tools, because
existing
ones provide pretty good environment to work
within.
Therefore focus on APIs and conventions seems very
reasonable to me.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
1) To have 9 pages rendering simultaneously you need to have very very high traffic. 2) We have systems with 500 connections to the database running just fine. It is easier to throw hardware on a well-known problem (at least to some extent) than to spend cycles over-engineering. 3) Think of caching the data if possible or think of implementing an aggregator that can send a single request on behalf of all components and distribute the results to them. - Original Message - From: "Rui Pacheco" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Tuesday, July 18, 2006 6:30 PM Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously. Still, if the components were all rendered at the same time, you would be tying up 9 connections simultaneously, and that would kill your response times. On 7/18/06, kranga <[EMAIL PROTECTED]> wrote: Yes I would be fine with opening/closing 9 connections to the database if they are from a connection pool because then I would be opening/closing 0 connections in reality! - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" Sent: Monday, July 17, 2006 12:48 PM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. > So, you'd be okay with opening/closing 9 connections to the database > during > each request cycle? I'd think it would be better to just use one > during > the > entire request cycle. > > -Original Message- > From: kranga [mailto:[EMAIL PROTECTED] > Sent: Monday, July 17, 2006 12:40 PM > To: Tapestry users > Subject: Re: A bit OT: how to manage database connections for multiple > components rendered simultaneously. > > Even if all components ask for their own connection, assuming > components > release connections when they are done, you would still expect only 1 > connection in use (though it may physically travel on upto 8 different > connection, there is only 1 connection open at any given time). > > A much better optimization would be to add an observer/mediator style > pattern - a "data provider" that each component is able to tell what data > it > > needs (perhaps in the renderComponent method) and when the first > request > for > > the data is made, the provider creates a SQL encompassing all requests, > gets > > it and is able to dish it out. However, I personally (without any more > info) > > would classify this optimization as pre-mature. 8 requests to the database > may only result in about 400ms while I have a monster elsewhere slowing > everything down. Plus you need to take into account how often the index > page > > is actually invoked. > > - Original Message - > From: "James Carman" <[EMAIL PROTECTED]> > To: "'Tapestry users'" > Sent: Monday, July 17, 2006 11:36 AM > Subject: RE: A bit OT: how to manage database connections for multiple > components rendered simultaneously. > > >> Unless all components ask for their own connection, which I think is what >> they were saying. >> >> -Original Message- >> From: kranga [mailto:[EMAIL PROTECTED] >> Sent: Monday, July 17, 2006 11:28 AM >> To: Tapestry users >> Subject: Re: A bit OT: how to manage database connections for multiple >> components rendered simultaneously. >> >> Unless I'm missing something, you will not be using 9 connections as the >> components will render in serial order. So you will make 9 requests over >> a >> single connection. >> >> - Original Message - >> From: "James Carman" <[EMAIL PROTECTED]> >> To: "'Tapestry users'" ; "'Tapestry users'" >> >> Sent: Monday, July 17, 2006 10:19 AM >> Subject: RE: A bit OT: how to manage database connections for multiple >> components rendered simultaneously. >> >> >>> All code within one request can easily just use one connection. That's >>> what >>> we do with Tapernate. >>> >>> -Original Message- >>> From: Rui Pacheco [mailto:[EMAIL PROTECTED] >>> Sent: Monday, July 17, 2006 10:13 AM >>> To: Tapestry users; Tapestry users >>> Subject: A bit OT: how to manage database connections for multiple >>> components rendered simultaneously. >>> >>> Hi all >>> >>> This is not a pure Tapestry question, but I believe you have seen >>> this >>> before and might be able to give me some guiding light. >>
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Yes I would be fine with opening/closing 9 connections to the database if they are from a connection pool because then I would be opening/closing 0 connections in reality! - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" Sent: Monday, July 17, 2006 12:48 PM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. So, you'd be okay with opening/closing 9 connections to the database during each request cycle? I'd think it would be better to just use one during the entire request cycle. -Original Message- From: kranga [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 12:40 PM To: Tapestry users Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously. Even if all components ask for their own connection, assuming components release connections when they are done, you would still expect only 1 connection in use (though it may physically travel on upto 8 different connection, there is only 1 connection open at any given time). A much better optimization would be to add an observer/mediator style pattern - a "data provider" that each component is able to tell what data it needs (perhaps in the renderComponent method) and when the first request for the data is made, the provider creates a SQL encompassing all requests, gets it and is able to dish it out. However, I personally (without any more info) would classify this optimization as pre-mature. 8 requests to the database may only result in about 400ms while I have a monster elsewhere slowing everything down. Plus you need to take into account how often the index page is actually invoked. - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" Sent: Monday, July 17, 2006 11:36 AM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. Unless all components ask for their own connection, which I think is what they were saying. -Original Message- From: kranga [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 11:28 AM To: Tapestry users Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously. Unless I'm missing something, you will not be using 9 connections as the components will render in serial order. So you will make 9 requests over a single connection. - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" ; "'Tapestry users'" Sent: Monday, July 17, 2006 10:19 AM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. All code within one request can easily just use one connection. That's what we do with Tapernate. -Original Message- From: Rui Pacheco [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 10:13 AM To: Tapestry users; Tapestry users Subject: A bit OT: how to manage database connections for multiple components rendered simultaneously. Hi all This is not a pure Tapestry question, but I believe you have seen this before and might be able to give me some guiding light. I have a web application, which I am splitting into several fragments, ie, components, each one rendering content stored in a database. I just realised my index page would have 9 such fragments and if each is to retrieve a connection from the pool to get its content, the stress on the db server might be crazy, even if each request is quite short. I have a connection pool, but even with that I don't believe its healthy to use 9 connections at the same time. What about the other users? How would you deal with this issue? -- Cumprimentos, Rui Pacheco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Even if all components ask for their own connection, assuming components release connections when they are done, you would still expect only 1 connection in use (though it may physically travel on upto 8 different connection, there is only 1 connection open at any given time). A much better optimization would be to add an observer/mediator style pattern - a "data provider" that each component is able to tell what data it needs (perhaps in the renderComponent method) and when the first request for the data is made, the provider creates a SQL encompassing all requests, gets it and is able to dish it out. However, I personally (without any more info) would classify this optimization as pre-mature. 8 requests to the database may only result in about 400ms while I have a monster elsewhere slowing everything down. Plus you need to take into account how often the index page is actually invoked. - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" Sent: Monday, July 17, 2006 11:36 AM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. Unless all components ask for their own connection, which I think is what they were saying. -Original Message- From: kranga [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 11:28 AM To: Tapestry users Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously. Unless I'm missing something, you will not be using 9 connections as the components will render in serial order. So you will make 9 requests over a single connection. - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" ; "'Tapestry users'" Sent: Monday, July 17, 2006 10:19 AM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. All code within one request can easily just use one connection. That's what we do with Tapernate. -Original Message- From: Rui Pacheco [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 10:13 AM To: Tapestry users; Tapestry users Subject: A bit OT: how to manage database connections for multiple components rendered simultaneously. Hi all This is not a pure Tapestry question, but I believe you have seen this before and might be able to give me some guiding light. I have a web application, which I am splitting into several fragments, ie, components, each one rendering content stored in a database. I just realised my index page would have 9 such fragments and if each is to retrieve a connection from the pool to get its content, the stress on the db server might be crazy, even if each request is quite short. I have a connection pool, but even with that I don't believe its healthy to use 9 connections at the same time. What about the other users? How would you deal with this issue? -- Cumprimentos, Rui Pacheco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Unless I'm missing something, you will not be using 9 connections as the components will render in serial order. So you will make 9 requests over a single connection. - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" ; "'Tapestry users'" Sent: Monday, July 17, 2006 10:19 AM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. All code within one request can easily just use one connection. That's what we do with Tapernate. -Original Message- From: Rui Pacheco [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 10:13 AM To: Tapestry users; Tapestry users Subject: A bit OT: how to manage database connections for multiple components rendered simultaneously. Hi all This is not a pure Tapestry question, but I believe you have seen this before and might be able to give me some guiding light. I have a web application, which I am splitting into several fragments, ie, components, each one rendering content stored in a database. I just realised my index page would have 9 such fragments and if each is to retrieve a connection from the pool to get its content, the stress on the db server might be crazy, even if each request is quite short. I have a connection pool, but even with that I don't believe its healthy to use 9 connections at the same time. What about the other users? How would you deal with this issue? -- Cumprimentos, Rui Pacheco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
User subscription email broken?
Apparently [EMAIL PROTECTED] is giving errors (no such email address). Does anyone know what the right email address is for users to subscribe? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 3 to 4.1 to 5
Duh! Yes, as you guys guessed, I meant Hivemind not Hibernate. I think I need to hibernate a little more and get my mind back ... Thanks for your input ... - Original Message - From: "kranga" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Saturday, June 24, 2006 8:05 PM Subject: Tapestry 3 to 4.1 to 5 We have a very large financial services applicaiton built with Tapestry 3 and it meets all the requirements for the project. But in looking ahead, I am trying to get some data to guide technology decisions for the project. My questions are: - Hibernate is used extensively in 4.x and though the principal is that you don't need to worry about Hibernate, the emails on this list make it look like a lot of deviations from defaults require Hibernate. Does anyone know if Hibernate is used outside of Tapestry? Specifically how is its user-base size and popularity when compared with Spring? - I've heard that 5 is not going to be backward compatible with 3. So that would give me absolutely no reason to upgrade to 4.x anytime soon. Is the 4.x to 5 incompatibility true? If so, it also seems like Tapestry is negatively skewed from a "business" perspective - high barrier to adopt the framework (the learning curve is higher and frankly it is almost impossible to find anyone in the market with Tapestry experience) but it provides a low barrier to exit - if versions are not going to be compatible and require significant effort, then why not evalulate other frameworks out there? - Anyone have experience comparing this with Echo 2? The echo 2 demo on their website does look impressive. Your thoughts are appreciated... KR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tapestry 3 to 4.1 to 5
We have a very large financial services applicaiton built with Tapestry 3 and it meets all the requirements for the project. But in looking ahead, I am trying to get some data to guide technology decisions for the project. My questions are: - Hibernate is used extensively in 4.x and though the principal is that you don't need to worry about Hibernate, the emails on this list make it look like a lot of deviations from defaults require Hibernate. Does anyone know if Hibernate is used outside of Tapestry? Specifically how is its user-base size and popularity when compared with Spring? - I've heard that 5 is not going to be backward compatible with 3. So that would give me absolutely no reason to upgrade to 4.x anytime soon. Is the 4.x to 5 incompatibility true? If so, it also seems like Tapestry is negatively skewed from a "business" perspective - high barrier to adopt the framework (the learning curve is higher and frankly it is almost impossible to find anyone in the market with Tapestry experience) but it provides a low barrier to exit - if versions are not going to be compatible and require significant effort, then why not evalulate other frameworks out there? - Anyone have experience comparing this with Echo 2? The echo 2 demo on their website does look impressive. Your thoughts are appreciated... KR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I do not like the new tapestry logo
Unicorn? Peugot symbol? - Original Message - From: "Peter Svensson" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Monday, May 15, 2006 6:41 AM Subject: Re: I do not like the new tapestry logo Hmm. The old one wasn't too good, but the new one feels more .. feminine in a way. Also more corporate. More stylish, to be sure. I'm undecided. Cheers, PS On 5/15/06, liigo <[EMAIL PROTECTED]> wrote: I'm sorry if I hurt someone. but i really like the old tapestry logo than the new one. maybe we need redesign another much better one. the new tapestry logo: http://svn.apache.org/viewcvs/tapestry/tapestry-logo/tapestry_logo_200x290.png?rev=406173&view=auto the old one: http://jakarta.apache.org/tapestry/images/Tapestry-Banner.png - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation on Tapestry 4
Hey, while we are on Tapestry Validation, has anyone read this article on a javascript validator combined with prototype library? Sounds like a cool alternative that might provide an alternative (and perhaps better?) model. http://tetlaw.id.au/view/blog/really-easy-field-validation-with-prototype/ - Original Message - From: "Pedro Viegas" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Wednesday, May 10, 2006 8:08 PM Subject: Re: Validation on Tapestry 4 Hi Rui, I feel a bit sad reading your comments. I have been browsing this list since a good friend of mine pointed it out to me like mandatory for a tapestry developer. I have been blessed with precious help from common folks like you and me, Tapestry gurus that do regular consulting work on Tap, and even Tapestry commiters who take the time to help us newbies with the real-life-not-so-motivating little or not so little problems. I myself am still on the very beginning of the process, and have been trying to start giving something back to the list out of shear gratitude of precisely what you're hinting the other way. I feel this list as the lighter atmosphere I have encountered. Everybody of every level of expertise now and again takes the time to help one another, very few posts go unanswered. Honestly I must state that you don't have to feel that way about this list. I'm sure that if you take the time you'll see for yourself that your current views, are not at all accurate. One more note. I must say you have been a little harsh on Sam. Not wanting to step on somebody's toes or go about defending who doesn't need defending, but I have been reading Sam's posts daily for a few days in this list. He has given very good contributions to the community, including the one for yourself, he has in the past days been loosing sleep working with the Tacos team to integrate a set of components he and his team has built in the past weeks into Tacos library for all us to use in the near future. Very quality work, free of charge and with no gain whatsoever to himself. So, you will understand why I had to post this opinion. The help you received was very to the point and all of us point out the book simply because... it's great!!! It's a very practical book that get's you developing right on it's first pages. As for Sam, well, with all I have described, it's ridiculous to state that a comment from him is contributing to a not so light atmosphere in this list. As I have posted in another topic after Sam's efforts provided with yet another component... praise Sam. :-) Just thought to set a few information here so that wrong impressions get carried away and the proper feedback due to contributors like Sam is given. Hope you read my intentions well. Best of luck on your tapestry learning path... best of luck to us both on this path, and rest assured your on the right place for gatting the help you need. Regards, On 5/11/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: I was not talking about specific cases, like my problem with validation which was admittedly my fault. What I want to say is that its not very friendly to send the URL of a book. It gives the impression that "I dont care". Sometimes, all we need is a holding hand. Dont want to start a flame war, but the folks over at the Wicket mailing list dont seem to be bothered with answering any and all questions. Granted, there are no books about Wicket, the framework is you and they want to draw developers. But the atmosphere is lighter. At least I feel more comfortable there. Once again, these are my views. Dont take this personally or as an attack on the framework. I love Tapestry and it is working up to what I expected it to be. On 5/11/06, Sam Gendler <[EMAIL PROTECTED]> wrote: > > On 5/10/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: > > Well, first, you reference it as Kent's book. Most people come to > Tapestry > > because a project landed on their laps and they need to get up to speed > > quickly. Referencing a book as "Kent's" is somewhat vague. > > > > Second, most of the time we just want quick answers. I know I didnt need > the > > book, I just needed some help clearing a couple of specific doubts. When > > we're looking for a quick answer, referencing the book is the same as > saying > > "go away". It sends the wrong vibe about the mailing list. > > I hate to disagree, but when someone is asking about a significant and > complex piece of functionality which is amply documented elsewhere, I > think it is perfectly legitimate to point them at that documentation, > rather than typing all the documentation into an email. I brought up > Kent's book (which costs money, admittedly) only because I felt that > his coverage of validation was superior to the standard Tap4 docs, and > because you'd already gotten a link to the standard docs, so I wanted > to make sure you knew about both sources. I also included the full > title of the book and mentioned where to find a link to it. I don't > real
