tapestry 4.0 src download?
-- View this message in context: http://www.nabble.com/tapestry-4.0-src-download--tf4297069.html#a12231202 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tapestry 4.0 src download?
you can use subversion to get the 4.0 source 4x versions are under: https://svn.apache.org/repos/asf/tapestry/tapestry4/branches the version you ask for https://svn.apache.org/repos/asf/tapestry/tapestry4/branches/4.0 you can use any svn client ... On 8/20/07, bhomass [EMAIL PROTECTED] wrote: the download link on http://tapestry.apache.org/tapestry4/downloads.htmlis dead. I am committed to 4.0 and need to find the source. is that available any where? please provide a link. I will accept the jar in email too. Thanks -- View this message in context: http://www.nabble.com/tapestry-4.0-src-download--tf4297069.html#a12231202 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Quotes in TextField component not escaped?
Bummer. That's a major omission - please log a JIRA issue. You may have to patch Tapestry directly to fix it. I'm surprised no-one has reported this before. (Luckily for me Japanese doesn't use those characters.) Cheers, Nick. Josh Canfield wrote: t:textfield t:id=title t:value=title size=50/ gets rendered to input id= title name=title size=50 type=text value=My quoted content I see a todo in org.apache.tapestry.dom.Element to URL encode the attributes... I haven't seen mention of it in the list, or in Jira, but it seems like a pretty common case so I'm hoping that I've missed something. Anyone know of a solution/workaround? Thanks, Josh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ValidationDelete Error Message Display and locale (!) translation
Does this link help: http://wiki.apache.org/tapestry/Tapestry5HowToOverrideTheDefaultErrorMessageBanner Cheers Erik On 8/17/07, ipoese [EMAIL PROTECTED] wrote: Hi Folks, for all those who cannot make much sense of my subject - sorry. I didn't know any better way of putting it, really. So, after i got validation working and figured out how to use the DelegationValidatior to display the Errors next to my input fields - here's the next... challenge :) Down to Business: i need those errors translated into the current locale i am using (currently i have two, but i need to be able to support more). I know how to do it using the message prefix on components and the key span in html, but how do i translate the acctual message thrown by the validator class ? do i have to do it manually ? if so, where can i go fetch the keys and corresponding translations for my current locale since i am really not up for specifying the translations in a Java class - that would be mighty ugly - or so i think... so, if any of you guys ran into that one before, i would really appreciate a some help. Thanks a lot in advanche -- View this message in context: http://www.nabble.com/ValidationDelete-Error-Message-Display-and-locale-%28%21%29-translation-tf4287771.html#a12206074 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] how to Eager Loading PERTHREAD_SCOPE service?
do you mean pooling? g,kris-"Davor Hrg" [EMAIL PROTECTED] schrieb: -An: "Tapestry users" users@tapestry.apache.orgVon: "Davor Hrg" [EMAIL PROTECTED]Datum: 19.08.2007 05:37PMThema: Re: [T5] how to Eager Loading PERTHREAD_SCOPE service?do you want your service loaded for each thread,and for each thread a new instance created ?why do you need this ?consider avoiding this ?who creates the threads ?Davor HrgOn 8/19/07, Jun Tsai [EMAIL PROTECTED] wrote: 2007/8/19, Ben Tomasini [EMAIL PROTECTED]: It seems to me that the normal eager load behavior would be irrelevant for a perthread service because a perthread service must be bound to a thread which is using the registry, and the registry cannot be used until it is built. I wanto to eager load the service at per thread. how to do ? -- regards, Jun Tsai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] how to Eager Loading PERTHREAD_SCOPE service?
Hi, try AOP ... (e.g. AspectJ) Jirka Jun Tsai napsal(a): 2007/8/19, Ben Tomasini [EMAIL PROTECTED]: It seems to me that the normal eager load behavior would be irrelevant for a perthread service because a perthread service must be bound to a thread which is using the registry, and the registry cannot be used until it is built. I wanto to eager load the service at per thread. how to do ? -- Jiří Mareš (mailto:[EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T4.1.2 BrowserEvent doesn't contain position in IE
I haven't played around with this at all, but if you think it is a bug, open
a JIRA issue and I'm sure Jesse will take a look at it. If it turns out to
not be a bug, it'll just get closed out anyway.
--
Kevin
On 8/17/07 10:31 PM, in article
[EMAIL PROTECTED], Daniel Kleine-Albers
[EMAIL PROTECTED] wrote:
Hi all,
The problem I'm experiencing only occurs in IE (6 and 7), Firefox is
working fine. It seems that the position information in BrowserEvent
is not populated when using IE.
I have an EventListener attached to a DIV element like this:
@EventListener(targets=createLinkLayer, events=onclick)
public void doAddLinkPosition(BrowserEvent event) {
log.debug(X: + event.getPageX() + Y: + event.getPageY()
+ Layer X: + event.getLayerX() + Y: +
event.getLayerY());
... doSomehting ...
}
If the event is triggered using Firefox everything is fine. If using
IE none of the positions (Page / Layer) is available - all return
null.
The problem appears in Jetty as well as Tomcat (although I don't
think this is relevant here).
Any ideas?
Thanks,
Daniel
-
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]
abstract or no
Hi, Some tutorials(like:http://www.devshed.com/c/a/Apache/Creating-Your-First-Tapestry-Project/) uses abstract class for page, while others use a regular class, which one is better? a.c. -- View this message in context: http://www.nabble.com/abstract-or-no-tf4298749.html#a12235434 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursion of components
As Howard has authored - it is Principle 1 of tapestry - see
http://tapestry.apache.org/tapestry5/ towards the bottom of the page.
Richard.
Nick Westgate wrote:
There's been plenty of discussion about this in the past, and using
blocks from a template is the usual solution, eg:
http://www.behindthesite.com/blog/C1931765677/E923478269/index.html
I believe the static structure, dynamic behaviour mantra is for the
sake of performance, and a fundamental framework design desicion.
But if you think it's a bug, log a JIRA. At least one of the new devs
might have an opinion about this, but they haven't been on the lists
much recently.
Cheers,
Nick.
[EMAIL PROTECTED] wrote:
Interesting, I hit this same wall a while ago when trying to render a
tree. It seems to be a common occurrence, so supporting it in the
framework would be highly desirable. I ended up doing almost all the
rendering in Java code, using the template only to hold blocks which I
called to render from the Java code. This allowed me to at least specify
some blocks of HTML in the template, rather than doing it all in code.
Damien
I couldn't believe it, so I made an example. And I had to discover that
it is true:
org.apache.tapestry.ioc.internal.util.TapestryException
The template for component example.recursive.components.Node is
recursive (contains another direct or indirect reference to component
example.recursive.components.Node). This is not supported (components
may not contain themselves).
I consider this a bug that has to do with the alpha state of T5.
Otherwise I have doubts on the usefulness of T5 at all.
Todd Orr wrote:
I'm also trying to perform this type of recursive structure. I don't
agree that this makes anything simpler. Recursion is a powerful and
concise tool for these situations. I will say that it is often abused,
but this is a perfect use case. A recursive solution to this problem
is far simpler and maybe more correct than this iterative approach.
First off, the proposed solution requires complicated logic. Fine,
it's not rocket science, but the recursive alternative (if there was
one in tap) is far easier to read and understand. From a
tech-management point of view the simplicity of the code is a major
factor in its long term maintainability as well as its bugginess.
Secondly, the proposed solution requires adding raw HTML output to
code. This may be a more esoteric and arguable point, but Tapestry
excels in having a clear and easy to use separation between the
view/presentation and the logic components of the application's
construction. Again, with regards to maintainability, it is twice as
hard to maintain code if the concerns are spread throughout
conceptually separate pieces of code.
Third, this approach makes it impossible for any node in the tree to
contain any non-trivial nested components. I see that you can create
links...wow. Kinda limiting if you ask me. This limits the usefulness
and extendability of the code. If more complex functionality is
required (lets say by a major client or some other critical business
need) within this pseudo-recursive implementation it might force the
developers to completely switch out frameworks to one more suitable
for the job. This is a huge risk from a business perspective.
While I think these points are painful enough on their own, it does
raise some questions about the framework's usefulness in specific
situations. My main concern is in relation to CMS features. Many
applications require support for some level of features that would be
considered CMS functionality. This static structure imposed makes
creating dynamic sites, well, painful. When you are attempting to
build an application that must adapt to known types of runtime or
user-configuration driven alterations that have many variants during
runtime (eg. depth of a tree, etc.) the static structure is limiting.
Tapestry is a great framework. However, the intention of the static
structure, while clearly advantageous in many respects, limits the use
case coverage for the framework at worst and makes certain otherwise
easy tasks very difficult at best.
Perhaps the rules for the static structure could be allowed to bend
from time to time as a nod to those of us that do require greater
flexibility. I'm sure this is easier suggested than done, but what are
the options?
On 7/17/07, Francois Armand [EMAIL PROTECTED] wrote:
Dmitry Sidorenko wrote:
Hi all.
Hi,
In my project I need to generate edit form for a class like this:
class Section{
ListSection subSectionList;
ListField fieldList;
}
[...]
Probably I'm doing something wrong, maybe my task should be done in
completely different manner.. Any ideas?
Is there any way to develop visual editor for such a recursive
classes?
I don't know how T4 works, but if it's like in T5, their is no
support
of recursive template/class.
So, for tree structure, you have to use a non-recursive algorithm (I
think that in your example, you wish to use a
Re: abstract or no
Hi Tapestry 4 relied more on abstract classes. In Tapestry 5, you are usually writing concrete classes -- tapestry does it's magic on all the classes under /pages. You can still have an abstract class to base your pages on, but that class should probably go in /base instead of /pages, since it wont have a page template of it's own. I believe this is covered on the Tapestry 5 main website. On 8/20/07, Angelo Chen [EMAIL PROTECTED] wrote: Hi, Some tutorials(like:http://www.devshed.com/c/a/Apache/Creating-Your-First-Tapestry-Project/) uses abstract class for page, while others use a regular class, which one is better? a.c. -- View this message in context: http://www.nabble.com/abstract-or-no-tf4298749.html#a12235434 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: T5 Validator
All, I've got a couple of completely functional valdators now and I wanted to post them with a quick howto on the wiki.one problem.I can't figure out how to create a new page.can someone provide some insight :-) I'm am using the DevWiki link on the tapestry 5 home page. -Cheers, Jon -Original Message- From: Chris Lewis [mailto:[EMAIL PROTECTED] Sent: Friday, August 17, 2007 11:04 AM To: Tapestry users Subject: Re: T5 Validator Another option is to provide and explicit banner parameter to the error component. You may not like having to set it explicitly, but I personally prefer doing that to overriding the prop file found on the class path (fyi, adding a 'default-banner' message to the application catalog doesn't work). It'd be nice if there were a simpler location to have these message catalogs.. Anyway, here's what your component might look like: t:errors banner=literal:Way to go jackass - you BLEW IT!/ chris Nick Westgate wrote: See: http://wiki.apache.org/tapestry/Tapestry5HowToOverrideTheDefaultErrorMessage Banner Also, when you get your validator working, please consider adding it to the wiki: http://wiki.apache.org/tapestry/Tapestry5HowTos Cheers, Nick. DougS wrote: Also, is it possible to override the default error message that shows at the top of the page (which says You must correct the following errors before you may continue.)? - 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] how to make page templates (like Tiles)
AFAIK, there is not a layout component, a layout is just a custom component you have to create (with your own template). see http://tapestry.apache.org/tapestry5/tapestry-core/guide/templates.html On 8/19/07, Anton Gavazuk [EMAIL PROTECTED] wrote: Hi Jun, Do you have an example or link to example :)? I have looked through mail list and found only messages related to layout component about CSS. 2007/8/19, Jun Tsai [EMAIL PROTECTED]: 2007/8/19, Anton Gavazuk [EMAIL PROTECTED]: Hello all, How to implement page templates using tapestry 5 - like a page definitions in Tiles? you can use layout component. -- regards, Jun Tsai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5 Validator
Actually I figured it out and the verdict is yes I am an idiotanywayif you go to the DevWiki(http://tapestry.apache.org/tapestry5/tap5devwiki.html) And search for ValidatorSamples you'll find my custom validatorshope this helps someoneI also provided the app module code for contributing new validation messages and the actual validators) Jon -Original Message- From: Jonathan Glanz [mailto:[EMAIL PROTECTED] Sent: Monday, August 20, 2007 8:19 AM To: 'Tapestry users' Subject: RE: T5 Validator All, I've got a couple of completely functional valdators now and I wanted to post them with a quick howto on the wiki.one problem.I can't figure out how to create a new page.can someone provide some insight :-) I'm am using the DevWiki link on the tapestry 5 home page. -Cheers, Jon -Original Message- From: Chris Lewis [mailto:[EMAIL PROTECTED] Sent: Friday, August 17, 2007 11:04 AM To: Tapestry users Subject: Re: T5 Validator Another option is to provide and explicit banner parameter to the error component. You may not like having to set it explicitly, but I personally prefer doing that to overriding the prop file found on the class path (fyi, adding a 'default-banner' message to the application catalog doesn't work). It'd be nice if there were a simpler location to have these message catalogs.. Anyway, here's what your component might look like: t:errors banner=literal:Way to go jackass - you BLEW IT!/ chris Nick Westgate wrote: See: http://wiki.apache.org/tapestry/Tapestry5HowToOverrideTheDefaultErrorMessage Banner Also, when you get your validator working, please consider adding it to the wiki: http://wiki.apache.org/tapestry/Tapestry5HowTos Cheers, Nick. DougS wrote: Also, is it possible to override the default error message that shows at the top of the page (which says You must correct the following errors before you may continue.)? - 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] BeanEditForm CSS suggestion
In general, Tapestry's defaults are good -- they get you up and
running. But for people who want to add more pieces of flair to the
components, we'll probably end up needing to copy the component and
make changes as needed. For example, rewriting the Grid component's
template to make changes to the DOM that gets output. Or adding more
CSS tags to the elements of the bean form, so we can make more
specific CSS changes if we want to.
As for the colon. it's plausible that you may want a question mark
after a field label, or perhaps in some locales you may not want a
prompt character at all.
For an immediate fix, without affecting your other submit buttons,
maybe you can wrap your bean edit form inside a div, and use that
div's class as a way to help target the submit button.
On 8/20/07, Kolesnikov, Alexander GNI
[EMAIL PROTECTED] wrote:
Thank you, Chris,
CSS2 has a lot of wonderful stuff in it, but the problem is that it
doesn't work consistently in different browsers. For example, your
solution works in Firefox, but not in IE6, the most popular Web browser
these days.
On the other hand, having a different style for the button area would
work in every browser, and it would allow someone to use a different
background for the button area too - why not?
Another style used for BeanEditForm I am not happy with is this:
FORM.t-beaneditor LABEL:after {
content: :;
}
Looks like a clever use of CSS2, but again, this doesn't work in both
IE6 and IE7. Also, in some other browsers (don't remember now, probably
Opera), the colon seems to be lower than the label, not properly
aligned. And, if you think about it, why not to have this colon
hard-coded? What else one would wish to place after the label instead of
a colon? A semicolon? :/
Alexander
-Original Message-
From: Chris Lewis [mailto:[EMAIL PROTECTED]
Sent: 17 August 2007 18:07
To: Tapestry users
Subject: Re: [T5] BeanEditForm CSS suggestion
Alexander,
You can use CSS2 attribute selectors to match only submit input types.
Try this:
div.t-beaneditor-row input[type=submit] { font-size: 20px; }
This will match only input elements of type submit.
chris
Kolesnikov, Alexander GNI wrote:
I wonder if it would make sense to use a different CSS class for the
DIV that contains the Submit button in BeanEditForm (not
t-beaneditor-row)? I am trying to tweak the button using
div.t-beaneditor-row input style, but whatever I do with it, the same
applies to all the other input elements in the form...
Alexander
--
CONFIDENTIALITY NOTICE: If you have received this email in error,
please immediately notify the sender by e-mail at the address shown.
This email transmission may contain confidential information. This
information is intended only for the use of the individual(s) or entity
to whom it is intended even if addressed incorrectly. Please delete it
from your files if you are not the intended recipient. Thank you for
your compliance. Copyright 2007 CIGNA
==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
CONFIDENTIALITY NOTICE: If you have received this email in error, please
immediately notify the sender by e-mail at the address shown. This email
transmission may contain confidential information. This information is
intended only for the use of the individual(s) or entity to whom it is
intended even if addressed incorrectly. Please delete it from your files if
you are not the intended recipient. Thank you for your compliance.
Copyright 2007 CIGNA
==
-
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] BeanEditForm CSS suggestion
You can extend the BeadEditForm instead of copying it can't you? That
would be a pain...
Daniel Jue wrote:
In general, Tapestry's defaults are good -- they get you up and
running. But for people who want to add more pieces of flair to the
components, we'll probably end up needing to copy the component and
make changes as needed. For example, rewriting the Grid component's
template to make changes to the DOM that gets output. Or adding more
CSS tags to the elements of the bean form, so we can make more
specific CSS changes if we want to.
As for the colon. it's plausible that you may want a question mark
after a field label, or perhaps in some locales you may not want a
prompt character at all.
For an immediate fix, without affecting your other submit buttons,
maybe you can wrap your bean edit form inside a div, and use that
div's class as a way to help target the submit button.
On 8/20/07, Kolesnikov, Alexander GNI
[EMAIL PROTECTED] wrote:
Thank you, Chris,
CSS2 has a lot of wonderful stuff in it, but the problem is that it
doesn't work consistently in different browsers. For example, your
solution works in Firefox, but not in IE6, the most popular Web browser
these days.
On the other hand, having a different style for the button area would
work in every browser, and it would allow someone to use a different
background for the button area too - why not?
Another style used for BeanEditForm I am not happy with is this:
FORM.t-beaneditor LABEL:after {
content: :;
}
Looks like a clever use of CSS2, but again, this doesn't work in both
IE6 and IE7. Also, in some other browsers (don't remember now, probably
Opera), the colon seems to be lower than the label, not properly
aligned. And, if you think about it, why not to have this colon
hard-coded? What else one would wish to place after the label instead of
a colon? A semicolon? :/
Alexander
-Original Message-
From: Chris Lewis [mailto:[EMAIL PROTECTED]
Sent: 17 August 2007 18:07
To: Tapestry users
Subject: Re: [T5] BeanEditForm CSS suggestion
Alexander,
You can use CSS2 attribute selectors to match only submit input types.
Try this:
div.t-beaneditor-row input[type=submit] { font-size: 20px; }
This will match only input elements of type submit.
chris
Kolesnikov, Alexander GNI wrote:
I wonder if it would make sense to use a different CSS class for the
DIV that contains the Submit button in BeanEditForm (not
t-beaneditor-row)? I am trying to tweak the button using
div.t-beaneditor-row input style, but whatever I do with it, the same
applies to all the other input elements in the form...
Alexander
--
CONFIDENTIALITY NOTICE: If you have received this email in error,
please immediately notify the sender by e-mail at the address shown.
This email transmission may contain confidential information. This
information is intended only for the use of the individual(s) or entity
to whom it is intended even if addressed incorrectly. Please delete it
from your files if you are not the intended recipient. Thank you for
your compliance. Copyright 2007 CIGNA
==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
CONFIDENTIALITY NOTICE: If you have received this email in error, please
immediately notify the sender by e-mail at the address shown. This email
transmission may contain confidential information. This information is
intended only for the use of the individual(s) or entity to whom it is intended
even if addressed incorrectly. Please delete it from your files if you are not
the intended recipient. Thank you for your compliance. Copyright 2007 CIGNA
==
-
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: Recursion of components
What's worth considering is that the reason it exists at all is purely an implementation detail. There is already a pseudo-dynamic component creating ability in Tapestry. Consider a Loop component that contains other components. Somehow, Tapestry, in this case, knows what to generate at runtime since the iterations in the loop can be completely unknown beforehand (db, config, etc. driven). However, putting one loop inside another freaks Tapestry out. This is just dumb. Treating a component differently based on its placement is not static, as HLS desires tap to be. It's completely modal. Whatever logic is used to dynamically create loop/grid/etc. components on the fly should be a basis for recursive components. I believe that this principle is its primary shortcoming. So much so that it could be the death of tapestry in certain development groups/communities. Consider a company that has decided to upgrade from struts to tapestry. It has years of man hours and tens of thousands of lines of code invested in its application. However, struts has been evaluated as a no-go for the app's future. If said business were to move to tapestry it's developers would encounter a very easy / quick framework and may be able to build out much of the existing app in short order. However, in cases where recursion is needed they will be up against a mt. everest of a learning curve who's result may stil be unsuitable. This alone is enough for business interests and concerned tech management to put a halt on tapestry. Also, consider that recursion is such a universally accepted and widely used concept (nevermind its usefulness) that existing companies are sure to have at least a few examples. Now, even though this example is stupid it is pretty much every single existing enterprise (since java folks love that word) level company in existence. Maybe it's not a migration from struts and maybe its not even recursion that's the problem, but every single company that has a non-trivial application will run into this situation. Sometimes they'll be able to solve it easily with iteration, sometimes they'll have to climb walls to do it, other times they'll say f* it and move onto another framework. To those of you that say fine, let them move onto another framework you're missing the point. Tapestry is easy to use, has a great learning curve, a healthy community, etc., etc., etc. Why make something so common and easy to do elsewhere so freakin hard in tapestry? It's completely backwards. While principle 1 might be static, the entire design is focused on ease of component creation (Tapestry is specifically designed to make creating new components very easy, as this is a routine approach when building applications. - same link). If it's specific design is failing, something is wrong. On 8/20/07, Richard Kirby [EMAIL PROTECTED] wrote: As Howard has authored - it is Principle 1 of tapestry - see http://tapestry.apache.org/tapestry5/ towards the bottom of the page. Richard. Nick Westgate wrote: There's been plenty of discussion about this in the past, and using blocks from a template is the usual solution, eg: http://www.behindthesite.com/blog/C1931765677/E923478269/index.html I believe the static structure, dynamic behaviour mantra is for the sake of performance, and a fundamental framework design desicion. But if you think it's a bug, log a JIRA. At least one of the new devs might have an opinion about this, but they haven't been on the lists much recently. Cheers, Nick. [EMAIL PROTECTED] wrote: Interesting, I hit this same wall a while ago when trying to render a tree. It seems to be a common occurrence, so supporting it in the framework would be highly desirable. I ended up doing almost all the rendering in Java code, using the template only to hold blocks which I called to render from the Java code. This allowed me to at least specify some blocks of HTML in the template, rather than doing it all in code. Damien I couldn't believe it, so I made an example. And I had to discover that it is true: org.apache.tapestry.ioc.internal.util.TapestryException The template for component example.recursive.components.Node is recursive (contains another direct or indirect reference to component example.recursive.components.Node). This is not supported (components may not contain themselves). I consider this a bug that has to do with the alpha state of T5. Otherwise I have doubts on the usefulness of T5 at all. Todd Orr wrote: I'm also trying to perform this type of recursive structure. I don't agree that this makes anything simpler. Recursion is a powerful and concise tool for these situations. I will say that it is often abused, but this is a perfect use case. A recursive solution to this problem is far simpler and maybe more correct than this iterative approach. First off, the proposed solution requires complicated logic. Fine, it's not rocket
[T5] Dynamic Image component re-runs the full page lifecycle
I thought I had a pretty slick dynamic image component using the examples from the list and wiki. Recently I noticed a performance problem and tracked it to excess database access. It seems that whatever page I embed the image component in gets fully re-loaded when the onImage action is trigged. When I discovered this I was using onActivate in my page class to load some data from the database. I switched to beginRender hoping that since I wasn't actually rendering the page it wouldn't get called, but that was wrong. I suppose that it makes sense to me that these methods would get called for cases where the component is doing something with data in the page, but in this case it doesn't. So, the question is; do I refactor and upgrade my Image Component to an Image page? Or is there a better design that I haven't seen/thought of yet? I guess the more I think about the problem a separate page, or a filter of some kind (haven't delved into that part of T5 yet) might be more appropriate for rendering the bytes for the dynamic image as it's really not related to the page that contains it per se... Thanks, Josh -- -- TheDailyTube.com. Sign up and get the best new videos on the internet delivered fresh to your inbox.
Tapestry Gallery Widget
Folks, Is there a GalleryWidget anywhere implemented in tapestry? Specifically I am looking for auto-paging features just like contrib:table This widget would layout links or images of for example auto parts or cars for sale while hosting a control bar for auto-paging. Thanks in advance. Best regards Ken in nashua _ A new home for Mom, no cleanup required. All starts here. http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] instantiate a component on the fly
Humm alway in my way So I try to enhance T5 to support some Ajax Features. 1 - I've Aliased the ComponentActionRequestHandler to use my own. 2 - Now if my ComponentAction is and ajax action ex : http://mySite/myPage.myComponent:ajax/99 I want try to instanciate my targeted component. So I need to have a ComponentLoader and especially a ComponentLoader. But after investigation and more and more I read the source code of Tapestry 5, more and more I feel that difference between Page and ComponentPageElement is very thin. So why I need a page to instantiate a ComponentPageElement (ComponentPageElementImpl), why a Component can't existe wihout a page ? Thanks
Re: [T5] instantiate a component on the fly
That's close to my opinion. I appreciate how people would like to create a new component on the fly, and I understand the use cases involving that. However, it goes against the grain of Tapestry. I've finally documented this, the concept of static structure and dynamic behavior. Once you allow some pages to have a different structure but the same name, much of what Tapestry is capable of doing is thrown away. It can't cache effectively, it can't operate in a cluster effectively. There's so much going on in the design that says if I know the page name, I can trust that the structure is identical even when its a different page instance and a different server in the cluster. I think it's very important that Tapestry store as little as possible in the session. The new in T5 redirect-after-action pattern does force you to store more data in the session (with huge benefits, and the option to store on the client instead) so there's a bit of a compromise going on. However, doing as Wicket and JSF and storing big chunks of page structure in the session (necessary to support runtime dynamic page structure) is something I'm fundamentally opposed to, given that there are quite satisfactory solutions, based on blocks and other structures. On 8/17/07, Mark Stang [EMAIL PROTECTED] wrote: In the past, and I haven't heard anything from Howard to make me think differently, this was not possible. Howard's view has been that there is no need to create a component on the fly. Instead the standard procedure is to embed it in a page and hide it until needed. hth. Mark J. Stang Software Engineer office: +1 303.468.2900 Ping Identity -Original Message- From: David Avenante [mailto:[EMAIL PROTECTED] Sent: Fri 8/17/2007 10:29 AM To: Tapestry users Subject: Re: [T5] instantiate a component on the fly Hum I not sure. My component is not define in class and is not define in the template = It's a really a NEW component. So as I can see there is a possibility with PageElementFactory.newComponentElement() that I can inject in my page. But there is too many parameters. I hope Tapestry give me a day a very simplistic way to do this. I continue my investigations. Thanks for the input Robert ;) -- 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: [T5] instantiate a component on the fly
On 8/21/07, Howard Lewis Ship [EMAIL PROTECTED] wrote: However, it goes against the grain of Tapestry. I've finally documented this, the concept of static structure and dynamic behavior. This seems to answer (or comment if you prefer) on other thread Recursion of components, nice! -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tapestry 4.0 src download?
thanks, found it and downloaded. -- View this message in context: http://www.nabble.com/tapestry-4.0-src-download--tf4297069.html#a12245369 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tapestry 4 or 5?
Hi, I'm new to Tapestry, I'm learning now Tapestry 4 for a coming project. I'd like to know if Tapestry 5 is ready? which route should I take, Tapestry 4 or 5 to develop the new project? Thanks. A.C. -- View this message in context: http://www.nabble.com/Tapestry-4-or-5--tf4302180.html#a12245900 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : Re: T5: date picker component
No, sorry, I do not. If you discover some weird behaviour due to some bug in the date picker please let me know. We have a issue tracker on the google-code project. 2007/8/17, Marcelo lotif [EMAIL PROTECTED]: Ted, do you have any example of your DatePicker inside a BeanEditForm? i'm trying to do it but i got this error 15:56:37.015 ERROR! [SocketListener0-1] org.apache.tapestry.internal.services.TemplateParserImpl.insideBody( TemplateParserImpl.java:313) 67 Content inside a Tapestry body element is not allowed (at classpath:br/com/javasoftware/representacoes/components/HSplitBorder.html, line 39, column 40). The content has been ignored. any hints? 2007/8/16, Ted Steen [EMAIL PROTECTED]: I think it would be nice to have a DateFormat parameter on the component which can default to the current locale. I will have a look at it.. 2007/8/16, Julien HENRY [EMAIL PROTECTED]: Hi, As I said on google bug tracker, a good idea would be to put the date format in a localizable property file. Typically, date format will depend on the user locale. But I don't know how to do this... sorry. Julien --- Ted Steen [EMAIL PROTECTED] a écrit : This is something we will work on for the next release of this component. All ideas on how to dynamically generate the java script ifFormat for this (depending on the SimpleDateFormat on the server side) are welcome. oh! and also how to get the DateTranslator in the module to parse it correctly. 2007/8/16, Marcelo lotif [EMAIL PROTECTED]: i was looking for it a few days ago... just one question: it will have an easy to set translator in the future? if i want to set my own format i'll have to recompile the module ... Thanks! 2007/8/13, Ted Steen [EMAIL PROTECTED]: Hi! A new version of our date picker component is released. Compability issues with 5.0.5 is resolved. There are new features in un-commited code here, sent to me by Martin Dietze, but we want to have a closer look before we add it. http://code.google.com/p/tapestry5-jscalendar/ -- /ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Atenciosamente, Marcelo Lotif -- /ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- /ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Atenciosamente, Marcelo Lotif -- /ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: abstract or no
Hi Daniel, Thanks for the reply, I'm learning Tapestry 4, from those samples I saw, it's ok to use either abtract or not as page class, so which one is better? maybe non abstract class to be compatible with Tapestry 5? I'm just evaluating frameworks for a coming project, is it advisable to use Tapestry 5 instead of 4? Thanks. A.C. Daniel Jue wrote: Hi Tapestry 4 relied more on abstract classes. In Tapestry 5, you are usually writing concrete classes -- tapestry does it's magic on all the classes under /pages. You can still have an abstract class to base your pages on, but that class should probably go in /base instead of /pages, since it wont have a page template of it's own. I believe this is covered on the Tapestry 5 main website. On 8/20/07, Angelo Chen [EMAIL PROTECTED] wrote: -- View this message in context: http://www.nabble.com/abstract-or-no-tf4298749.html#a12246721 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: abstract or no
If you can wait for AJAX functionality (late 2007?) , I would say go with Tapestry 5. If you need AJAX immediately, the latest Tapestry 4 is best. Tapestry 5 is the next generation Tapestry, and the T4 code is not directly compatible. That said, your T4 code isn't completely useless either. T5 is still very component based. I've only worked with Tapestry 4 and 5, and I would say that Tapestry 5 is easier to learn, although for many people it's been a challenge to get started initially (mostly due to quickstart directions that weren't updated, regarding Maven). Also some T5 quickstarts included a few lines of code that needed to be changed or removed in order for the code to work. Don't be discouraged if it doesn't all come together at once -- people who have it running seem to love it, even though it is not fully completed. Maven's a great tool, and after you learn the basics I think newcomers will like it. There is a free ebook on the web that will teach you more that you'll need to know about Maven. In Tapestry 5, almost everything you'll need to write is a non abstract class. The directory structure of your web application is much better defined, IMHO. One of the best things is that there are no more xml files for your pages. For me it made things much simpler. I'm not a Tapestry expert by any means, and I sometimes find myself wanting to do things the hard way. Luckily there are a lot of nice people on this list who have politely corrected me, and shown me the better way. In addition there is a wiki page for T5 that is actively updated. I'm only a junior developer, so I try to add simple things that would help out people like myself. But others add more advanced how-to's. You might want to take a look, since it also links to sample code included in Tapestry. From there you can get a feel of how it works. http://wiki.apache.org/tapestry/Tapestry5HowTos On 8/20/07, Angelo Chen [EMAIL PROTECTED] wrote: Hi Daniel, Thanks for the reply, I'm learning Tapestry 4, from those samples I saw, it's ok to use either abtract or not as page class, so which one is better? maybe non abstract class to be compatible with Tapestry 5? I'm just evaluating frameworks for a coming project, is it advisable to use Tapestry 5 instead of 4? Thanks. A.C. Daniel Jue wrote: Hi Tapestry 4 relied more on abstract classes. In Tapestry 5, you are usually writing concrete classes -- tapestry does it's magic on all the classes under /pages. You can still have an abstract class to base your pages on, but that class should probably go in /base instead of /pages, since it wont have a page template of it's own. I believe this is covered on the Tapestry 5 main website. On 8/20/07, Angelo Chen [EMAIL PROTECTED] wrote: -- View this message in context: http://www.nabble.com/abstract-or-no-tf4298749.html#a12246721 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]
