Re: T5: Escaping espansions
Using outputRaw in combination with literal: did not work. Neither did a
CDATA section.
I worked around that problem by using a properties file for the text.
Hans Joerg
SergeEby wrote:
Hi,
Did you try the literal: binding prefix?
---
/Serge
Hans Jörg Hessmann wrote:
Hi,
I'd like to show a static text containing ${something} on a page. Is
there a way to escape the ${?
Thanks,
Hans Joerg Hessmann
-
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: Escaping espansions
Hi,
I'd like to show a static text containing ${something} on a page. Is
there a way to escape the ${?
Thanks,
Hans Joerg Hessmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursion of components
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 non-recursive preorder
traversal).
It's not really natural, but the non-support of recursive structure
seems to bring a lots of simplification with it.
You can look at this How To entry :
http://wiki.apache.org/tapestry/Tapestry5HowToCreateYourOwnComponents
I wish it would help.
Francois
-
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]
--
SPRICOM Informatik GmbH
Firmensitz: Brucknerstraße 29, 53721 Siegburg
Registergericht: Amtsgericht Siegburg, HRB 8808
Geschäftsführer: Hans Jörg Hessmann
http://www.spricom.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks in Tapestry 4.1
There is an excellent tool for post-mortem memory analyzation: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d0eaafd5-6ffd-2910-019c-9007a92b392f. Just add -XX:+HeapDumpOnOutOfMemoryError to the startup parameters of your JVM. This will produce a memory dump when your JVM dies because of an OutOfMemoryError. With the memory analyzer you can see which objects consumed all the memory and find out the cause for the the garbage collector not collecting them. (See the corresponding documentation and the wiki to find out how to do this.) Todd Orr wrote: True enough. I'll get more details from our side. I was merely pointing in that direction based on experience. On 8/9/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Whatever this mysterious issue is that you seem to think exists it'd be impossible to fix whatever memory leaks you think you have found without knowing about them. There is a map that grows as large as the system using it internally to javassist of various cached reflection info - but it doesn't leak in any way. Anyways, vague comments with no specific versions or specific issues that you have faced don't really help anyone. On 8/9/07, Todd Orr [EMAIL PROTECTED] wrote: We've run into this problem on a production system. It was a not a good situation. One of our developers narrowed down the issue to Hivemind. There is some Map that continually grows and grows (I can speak to our dev to get more detail). After some research into similar posts it became evident that this issue was brought up to HLS, but the bug's existence was denied. We've since dropped Tapestry for mission critical apps. I'm hoping this is no longer an issue in future versions of Tapestry, but time will tell. On 8/9/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Tapestry 4.1.2 has no memory leaks. Each and every object created / managed is accounted for and known. I've done a lot of analysis in this area lately which is why I'm so sure. On 8/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Within one day it rises slowly from 100 MByte to about 1 Gigabyte at night when it crashes due to the limt that was set to the virtual machine. It could be increased - but only with the effect of having an additional day or so before it crashes again.restarting Tomcat is also not a viable solution. Original-Nachricht Datum: Thu, 09 Aug 2007 17:01:19 +0200 Von: [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: Memory leaks in Tapestry 4.1 We have tried both enabling and disabling the cache. The same effect... it is only leaking a little bit slower in the other case. Original-Nachricht Datum: Thu, 9 Aug 2007 15:33:43 +0200 Von: Kristian Marinkovic [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: Memory leaks in Tapestry 4.1 do you have Tapestry caching deactivated? andyhot [EMAIL PROTECTED] Gesendet von: Andreas Andreou [EMAIL PROTECTED] 09.08.2007 15:28 Bitte antworten an Tapestry users users@tapestry.apache.org An Tapestry users users@tapestry.apache.org Kopie Thema Re: Memory leaks in Tapestry 4.1 Well, we did lots of tests with 4.1.2 and have yet to observe such memory leaks. [EMAIL PROTECTED] wrote: Have you ever observed the memory usage for your Tapestry application? For example, make a simple HelloWorld Application and load the page regularly using HTTP_LOAD. Then watch how the memory consumption grows and grows especially after an hour. Has anyone got a solution how avoid this leakage? - 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] -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.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
Re: maven build from source is not working.
I remember I had same problem once when I tried to compile some 5.0.5 snapshot
from subversion using maven 2.0.7. I think I solved this by modifiying the
tapestry-project/pom.xml like this:
dependency
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-test/artifactId
version${project.version}/version
!-- scopetest/scope --
/dependency
This problem disappeared in the 5.0.6 snapshots. Please try the most current
version from svn.
Hans Jörg Hessmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
