Component LinkSubmit doesn't work
I'm found this problem since in 5.1.0.5 (stable), in 5.0.0.18 LinkSubmit work
properly.
Linksubmit inside a form didn't fire events while no required property is
defined inside the form:
if you add
@Property
@Validate("required")
private String somefield;
in java and
in tml
your LinkSubmit began event capture
This is a huge limitation for the developers, particularly if you want to
filter a object (entity) view this behavior doesn't help much.
The issue https://issues.apache.org/jira/browse/TAP5-389 describe somthing
similar, but not in this tapestry version (5.1.0.5) and is closed in the
meantime.
--
View this message in context:
http://n2.nabble.com/Component-LinkSubmit-doesn%27t-work-tp2879193p2879193.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Clojure @ JavaWorld
Is JVM getting bloated with more programming concepts than just OOP? Is OOP on decline and more mathematical programming concepts on the rise? -Hari --- On Wed, 5/13/09, Howard wrote: > From: Howard > Subject: [Tapestry Central] Clojure @ JavaWorld > To: users@tapestry.apache.org > Date: Wednesday, May 13, 2009, 1:57 AM > Another nice introduction to Clojure is now online: Clojure: > Challenge > your Java Assumptions at JavaWorld. An introductory > Tapestry article is > due at JavaWorld shortly as well. > > -- > Posted By Howard to Tapestry Central at 5/12/2009 01:26:00 > PM - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Solving the T5 Documentation Dilemma
+1 for Official docs and User docs, and +1 for tapestry forum 2009/5/1 Otho > I would suggest splitting the documentation. > > There should be the reference documentation by the creators/commiters of > the > project, whis is organized like a book covering all the different aspects > of > tapestry 5 in a reference manner eg like spring or hibernate docs. These > are > tied to the release version, too. > > And then there should be the community docs with tutorials, howto's, > recipes > and so on on a wiki. There should be a pattern in the templates which > requires or at least pushes you, to mention the version of Tapestry you are > using. > > And lastly I would suggest setting up a forum. Information is more easily > organized there and searching is more convenient than wíth a mailing list > alone. I would think that the barrier of contributing to a forum is lower > than that of contributing to / asking on a mailinglist. Well, the latter > can > also be seen as a feature in a way, but publicity and visibility never > really hurt IMO. > > 2009/4/30 Piero Sartini > > > > I don't think Tapestry's wiki, http://wiki.apache.org/tapestry, is up > > > to the task. > > > > Confluence is available with apache as well. There is already a space > > available at http://cwiki.apache.org/TAPESTRY/ ... maybe its just a > matter > > of > > adding content to it? > > > > Anyway.. on Tapestry360 someone would not need to sign a CLA to > contribute > > to > > the documentation. > > > >Piero > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > >
Re: How do I remove the yellow-fade that occurs when updating the Zone component?
The update parameter of the zone component can take one of the following functions defined in Tapestry.ElementEffect object: show highlight slidedown slideup fade If you just want the zone to be updated with no effect use "show" like: On Tue, May 12, 2009 at 00:15, Sean Bollin wrote: > Hello, > > I would like to remove the yellow-fade that occurs while updating the Zone > component. > > I have tried the following: > > > > But it does not change the behavior. Please advise. > > Thank you, > Sean > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: How do I remove the yellow-fade that occurs when updating the Zone component?
The update function should have a parameter
Tapestry.ElementEffect = {
doNothing: function(element){
alert('Yep, it works!');
}
}
Furthermore, if you use 5.0.18 you may need to set the symbol
SymbolConstants.html#SCRIPTS_AT_TOP to true. This symbol is deprecated in
5.1.0.5.
On Wed, May 13, 2009 at 12:53 AM, Sean Bollin wrote:
> Nope.. this doesn't work. Thanks though.
>
> Any ideas?
>
> Inge Solvoll wrote:
>
>>
>> http://tapestry.apache.org/tapestry5.1/tapestry-core/ref/org/apache/tapestry5/corelib/components/Zone.html
>>
>> "The show and update parameters are the names of functions attached to the
>> Tapestry.ElementEffect object."
>>
>> So, if you want to create your own custom behaviour, you have to do this,
>> I think:
>>
>>
>> Tapestry.ElementEffect.prototype.doNothing = function() {};
>>
>>
>>
>>
>>
>> On Tue, May 12, 2009 at 1:15 AM, Sean Bollin > sbol...@sfeveo.com>> wrote:
>>
>>Hello,
>>
>>I would like to remove the yellow-fade that occurs while updating
>>the Zone component.
>>
>>I have tried the following:
>>
>>>t:update="fakeFunction()">
>>
>>But it does not change the behavior. Please advise.
>>
>>Thank you,
>>Sean
>>
>>-
>>To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>
>>For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: How do I remove the yellow-fade that occurs when updating the Zone component?
Nope.. this doesn't work. Thanks though.
Any ideas?
Inge Solvoll wrote:
http://tapestry.apache.org/tapestry5.1/tapestry-core/ref/org/apache/tapestry5/corelib/components/Zone.html
"The show and update parameters are the names of functions attached to
the Tapestry.ElementEffect object."
So, if you want to create your own custom behaviour, you have to do
this, I think:
Tapestry.ElementEffect.prototype.doNothing = function() {};
On Tue, May 12, 2009 at 1:15 AM, Sean Bollin > wrote:
Hello,
I would like to remove the yellow-fade that occurs while updating
the Zone component.
I have tried the following:
But it does not change the behavior. Please advise.
Thank you,
Sean
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Benchmarking Tapestry
Session or no, T5 still uses pooled pages; there's just an incremental cost for each additional persisted field; since few pages have more than a couple, this is rarely a problem. And it means that generally, the values stored in the HttpSession are small immutables, such as Integer or String. Not always ... Form's will store a bunch of mutable client validation data in the session. On Tue, May 12, 2009 at 1:19 PM, Neil Curzon wrote: >> >> >> > >> > All of my page views were done without a session, and it seems that >> Wicket's >> > raw performance advantage will only increase when the session comes into >> > play. I understand that will come at the cost of scalability via >> clustering >> > and memory consumption, though. I do agree that there are many details >> that >> > need to be taken into account. >> > >> >> I don't follow you here; I don't see a reason why adding a HttpSession >> to the mix would affect either framework more than the other ... until >> you hit a cluster, then T5 should (in theory) have an advantage. > > > > I extrapolated that from this, from the front tapestry 5 page: > > --- > > Tapestry does not need to store page instances inside the HttpSession. At > most, it stores a smattering of *persistent field values* from the page, but > not the entire page instance. This lean use of the HttpSession is key to > Tapestry's very high scalability, especially in a clustered configuration. > > In some Tapestry-like frameworks, such as Faces and Wicket, the page > structure is more dynamic, at the cost of storing much, much more data in > the HttpSession. > --- > > I'd imagine that would have at least a slight space/time tradeoff? (no need > to grab anything from a page pool at the cost of expensive replication). > Maybe negligible, though..? Now that I think of in, in Wicket there's a lot > of direct use of "new", so I probably had the wrong idea. > > Neil > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T4]CascadingDropDown component rewind problem?
You basically want to ensure that the same code path is executed both during render and on rewind. So, take a look at all your @If and @For components inside the form... also checkout their volatile parameter, .e.t.c. On Tue, May 12, 2009 at 4:25 PM, oliverlee000 wrote: > hi everyone!! > > i am using a cascading drop down component in my html form,but when i submit > form i got the exception like this, > > Rewind of form test/TabTest$TablePage.$Form expected allocated id #3 to be > 'parentId_0', but was 'childId' > (requested by component test/TabTest/$DynamicPropertySelection_0). > > who can tell me the reason of this exception,i still not understand the > rewind quite well,thanks a lot!! > > > 2009-05-12 > > > > oliverlee000 > -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Tapestry / Tacos developer Open Source / JEE Consulting - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
[Tapestry Central] Clojure @ JavaWorld
Another nice introduction to Clojure is now online: Clojure: Challenge your Java Assumptions at JavaWorld. An introductory Tapestry article is due at JavaWorld shortly as well. -- Posted By Howard to Tapestry Central at 5/12/2009 01:26:00 PM
Re: Benchmarking Tapestry
> > > > > > All of my page views were done without a session, and it seems that > Wicket's > > raw performance advantage will only increase when the session comes into > > play. I understand that will come at the cost of scalability via > clustering > > and memory consumption, though. I do agree that there are many details > that > > need to be taken into account. > > > > I don't follow you here; I don't see a reason why adding a HttpSession > to the mix would affect either framework more than the other ... until > you hit a cluster, then T5 should (in theory) have an advantage. I extrapolated that from this, from the front tapestry 5 page: --- Tapestry does not need to store page instances inside the HttpSession. At most, it stores a smattering of *persistent field values* from the page, but not the entire page instance. This lean use of the HttpSession is key to Tapestry's very high scalability, especially in a clustered configuration. In some Tapestry-like frameworks, such as Faces and Wicket, the page structure is more dynamic, at the cost of storing much, much more data in the HttpSession. --- I'd imagine that would have at least a slight space/time tradeoff? (no need to grab anything from a page pool at the cost of expensive replication). Maybe negligible, though..? Now that I think of in, in Wicket there's a lot of direct use of "new", so I probably had the wrong idea. Neil
Re: Benchmarking Tapestry
On Tue, May 12, 2009 at 1:00 PM, Neil Curzon wrote: > Well, whether a page view is executed in one framework or another, the same > calls into the service layer should be made, and the same persistence > queries should be executed. As long as the frameworks' component lifecycles > are co-operative with the design of your application (big if?), the load on > the other tiers should be constant. I think that the relative cost of simply > throwing some plain HTML together, if it is indeed adding 13+ms to every > request, is relevant. > > But yeah, a more advanced web framework may give you the power to implement > a more efficient solution with less development effort. There is a lot of > grumbling about Tapestry documentation, but Tapestry has Wicket soundly > beaten there. Thanks! There's lots of room for meta-programming in T5 that isn't present in Wicket. > > All of my page views were done without a session, and it seems that Wicket's > raw performance advantage will only increase when the session comes into > play. I understand that will come at the cost of scalability via clustering > and memory consumption, though. I do agree that there are many details that > need to be taken into account. > I don't follow you here; I don't see a reason why adding a HttpSession to the mix would affect either framework more than the other ... until you hit a cluster, then T5 should (in theory) have an advantage. > The problem is that I can't actually compare a real application in Tapestry > vs Wicket without first implementing that application. And, unfortunately, I > can only choose one framework, and must choose one first. > A common problem. > Neil > > On Tue, May 12, 2009 at 3:23 PM, Christian Edward Gruber < > christianedwardgru...@gmail.com> wrote: > >> >> On May 12, 2009, at 2:47 PM, Neil Curzon wrote: >> >>> I think it should be possible to reason about the web framework >>> independently from the back end. >>> >> >> >> However it just ain't so. If the front-ends had equivalent architectural >> impact, then sure. Or if everything were serial, then sure. However, a >> front end can behave differently with minimal back-end activity vs. a high >> degree of back-end activity, simply because it may be able to work or cache >> work product in one scenario that isn't possible in the other, or where the >> margins are so tight that such effort is a higher percentage of the total >> work done. Real end-to-end performance on a request is subject to a lot of >> architectural constraints, when it comes to measuring, and you can't do a >> straight-line computation from a no-op case. >> >> For example, the design of T5 may be such that a page constructed with a >> lot of javascript from different components is handled better than with >> taglibs, since T5 can bundle it up, call it a versioned asset, send it as >> one single compressed stream, and cache it on the client. If the other >> framework handles the JS file-by-file, without compression, and has to >> re-fresh more frequently, then it's possible that T5 can vastly outperform >> the other in a complex application, by design. >> >> cheers, >> Christian Edward Gruber >> christianedwardgru...@gmail.com >> http://www.geekinasuit.com/ >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Benchmarking Tapestry
Well, whether a page view is executed in one framework or another, the same calls into the service layer should be made, and the same persistence queries should be executed. As long as the frameworks' component lifecycles are co-operative with the design of your application (big if?), the load on the other tiers should be constant. I think that the relative cost of simply throwing some plain HTML together, if it is indeed adding 13+ms to every request, is relevant. But yeah, a more advanced web framework may give you the power to implement a more efficient solution with less development effort. There is a lot of grumbling about Tapestry documentation, but Tapestry has Wicket soundly beaten there. All of my page views were done without a session, and it seems that Wicket's raw performance advantage will only increase when the session comes into play. I understand that will come at the cost of scalability via clustering and memory consumption, though. I do agree that there are many details that need to be taken into account. The problem is that I can't actually compare a real application in Tapestry vs Wicket without first implementing that application. And, unfortunately, I can only choose one framework, and must choose one first. Neil On Tue, May 12, 2009 at 3:23 PM, Christian Edward Gruber < christianedwardgru...@gmail.com> wrote: > > On May 12, 2009, at 2:47 PM, Neil Curzon wrote: > >> I think it should be possible to reason about the web framework >> independently from the back end. >> > > > However it just ain't so. If the front-ends had equivalent architectural > impact, then sure. Or if everything were serial, then sure. However, a > front end can behave differently with minimal back-end activity vs. a high > degree of back-end activity, simply because it may be able to work or cache > work product in one scenario that isn't possible in the other, or where the > margins are so tight that such effort is a higher percentage of the total > work done. Real end-to-end performance on a request is subject to a lot of > architectural constraints, when it comes to measuring, and you can't do a > straight-line computation from a no-op case. > > For example, the design of T5 may be such that a page constructed with a > lot of javascript from different components is handled better than with > taglibs, since T5 can bundle it up, call it a versioned asset, send it as > one single compressed stream, and cache it on the client. If the other > framework handles the JS file-by-file, without compression, and has to > re-fresh more frequently, then it's possible that T5 can vastly outperform > the other in a complex application, by design. > > cheers, > Christian Edward Gruber > christianedwardgru...@gmail.com > http://www.geekinasuit.com/ > > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Benchmarking Tapestry
On May 12, 2009, at 2:47 PM, Neil Curzon wrote: I think it should be possible to reason about the web framework independently from the back end. However it just ain't so. If the front-ends had equivalent architectural impact, then sure. Or if everything were serial, then sure. However, a front end can behave differently with minimal back- end activity vs. a high degree of back-end activity, simply because it may be able to work or cache work product in one scenario that isn't possible in the other, or where the margins are so tight that such effort is a higher percentage of the total work done. Real end-to-end performance on a request is subject to a lot of architectural constraints, when it comes to measuring, and you can't do a straight- line computation from a no-op case. For example, the design of T5 may be such that a page constructed with a lot of javascript from different components is handled better than with taglibs, since T5 can bundle it up, call it a versioned asset, send it as one single compressed stream, and cache it on the client. If the other framework handles the JS file-by-file, without compression, and has to re-fresh more frequently, then it's possible that T5 can vastly outperform the other in a complex application, by design. cheers, Christian Edward Gruber christianedwardgru...@gmail.com http://www.geekinasuit.com/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Benchmarking Tapestry
Thanks for your input everyone.
I don't exactly expect the web framework to be the bottleneck at 700+
requests per second, but I'm keeping these things in mind too. I think it
should be possible to reason about the web framework independently from the
back end. In our case it will be the exact same business logic / persistence
layer we'll be connecting.
So I tried out Tapestry 5.1.0.5, and I'm noticing some really weird behavior
that's also present in 5.0.18.
I start out by benchmarking serial requests: only one thread making 100
random requests. Tapestry is really quick here:
Requests per second:392.15686274509807
Average resp time (ms): 2.15
I can run this many times in a row, with the same approximate result. Then,
I switch to benchmarking 10 threads each making 100 random requests:
Requests per second:456.62100456621005
Average resp time (ms): 19.161
But now, it gets weird. When I go back to one thread making 100 requests:
Requests per second:48.4027105517909
Average resp time (ms): 19.74
The numbers are very similar in 5.1 and 5.0, and the behavior is the same,
with a spike in parallel traffic permanently damaging the single threaded
response time. Only a server restart seemed to get back to the 2ms response
time. When I use the same environment to try the same serial, parallel,
serial test in wicket, there is no such problem, so I think Tapestry is the
cause here.
Setting the hard and soft limits to 40 and 50 respectively did not change
this behavior. Google showed this be the way:
configuration.add("tapestry.page-pool.soft-limit", "40");
configuration.add("tapestry.page-pool.hard-limit", "50");
.. is that correct?
I'm benchmarking in jetty, and I'm not sure what the default thread pool
size is, but on the client side, it's not more than 10, so I thought that
40/50 would be enough..?
Neil
Re: T5: Passing named/structured-type params in URLs?
Hi Andy,
The same Encoder could indeed be used across multiple pages.
Some pointers:
You need to create one of these:
http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/ValueEncoder.html
Look at the source for one of the existing implementation for ideas,
e.g. StringEncoder
I've attached an example implementation of a MapValueEncoder.java
You will then need to configure your Tap App to use your encoder e.g.
public static void
contributeValueEncoderSource(MappedConfiguration configuration) {
configuration.add(Map.class, new
GenericValueEncoderFactory(new
MapValueEncoder()));
}
You can then have activation context's that take a Map e.g.
protected boolean onActivate(Map params) {
id = params.get("id");
}
I'm sure there is a doc page for encoders, although I cann't seem to dig
it out.
-Original Message-
From: Andy Buckley
Reply-To: Tapestry users
To: Tapestry users
Subject: Re: T5: Passing named/structured-type params in URLs?
Date: Tue, 12 May 2009 16:07:06 +0100
Joel Halbert wrote:
> There was a jira feature request raised for named params some time ago:
> https://issues.apache.org/jira/browse/TAP5-264
>
>
> Andy - in the meantime, another alternative is to create a custom
> ValueEncoder for activation contexts which can encode and decode a map.
> You could then encode the map context using a scheme which uses, for
> example, underscores as delimiters, such as:
>
> /mypage/name1_value1_name2_value2
> (i.e. /mypage/)
>
> This would allow you to access params by name from an activation
> context.
>
> This works well enough so long as you do not care about using the
> correct http request syntax for query strings
> (?name1=value1&name2=value2).
I've ended up essentially doing this, but more manually via the
onActivate() method of the page. Can you point me at any documentation
on how to do this with a custom ValueEncoder as you've suggested, and
what the benefits would be of doing it that way? (e.g. would this make
it easy to use the same param value encoding scheme on multiple pages?)
Cheers,
Andy
import java.io.UnsupportedEncodingException;
import java.net.URLDecoder;
import java.net.URLEncoder;
import java.util.Iterator;
import java.util.Map;
import org.apache.commons.collections.map.ListOrderedMap;
import org.apache.log4j.Logger;
import org.apache.tapestry5.ValueEncoder;
public class MapValueEncoder implements ValueEncoder {
static final Logger log = Logger.getLogger(MapValueEncoder.class);
private static final String DELIM = "_";
@Override
public String toClient(Object value) {
String res = "";
Iterator it = null;
Map map = (Map) value;
if (value instanceof ListOrderedMap) {
ListOrderedMap lomap = (ListOrderedMap) value;
it = lomap.keyList().iterator();
} else {
it = map.keySet().iterator();
}
while(it.hasNext()) {
String key = it.next();
Object val = map.get(key);
if (val != null) {
if (res.length() > 0) {
res += DELIM;
}
res += key + DELIM + escapeString(val.toString());
}
}
return res;
}
@Override
public Object toValue(String clientValue) {
String[] tokens = clientValue.split(DELIM);
ListOrderedMap res = new ListOrderedMap();
boolean tokIsKey = true;
String currKey = null;
for (int i = 0; i < tokens.length; i++) {
String tok = tokens[i];
if (tokIsKey) {
currKey = tok;
} else {
res.put(currKey, descapeString(tok));
}
tokIsKey = !tokIsKey;
}
return res;
}
public static String escapeString(String string) {
try {
return URLEncoder.encode(string, "UTF-8");
} catch (UnsupportedEncodingException e) {
log.error("unable to encode : " + string, e);
return "";
}
}
public static String descapeString(String string) {
try {
return URLDecoder.decode(string, "UTF-8");
} catch (UnsupportedEncodingException e) {
log.error("unable to descape : " + string, e);
return "";
}
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Ognl issues in tapestry 4.1.6
It would be helpful to see the Domain class. Perhaps there's an
overloaded method that's confusing the OGNL code. As you can see, it's
trying to generate bytecode for your expression, but failing for some
reason. Classloader issues can get very tricky inside this kind of
code.
On Tue, May 12, 2009 at 8:12 AM, wrote:
>
> Hi
> Ognl in 4.1.6 is behaving rather strangely(I believe this must be a bug)!
> We're trying to upgrade from 4.0.2.
> Here's a simplified version of what's happening in an insert component.
> value="ognl:content.domain['startDate']" renders correctly however
> value="ognl:content.domain[sharedPickerProperty]" where sharedPickerProperty
> is a property of the page and has initial-value="literal:startDate" results in
> org.apache.tapestry.services.impl.HiveMindExpressionCompiler]
> context=/opvantage - Error generating OGNL getter for expression
> content.domain[sharedPickerProperty] with root $domainbase...@3c1[edit:Event]
> and body:
> { return
> ((com.algorithmics.opvantage.model.domain.Event)(($DomainBase_42)$2).getContent().getDomain()).getStartDate();}
> org.apache.hivemind.ApplicationRuntimeException: Unable to add method
> java.lang.Object get(ognl.OgnlContext, java.lang.Object) to class
> $ASTChain_121354aa5aa: [source error] no such class:
> com.algorithmics.opvantage.model.domain.Event
>
> Now obviously com.algorithmics.opvantage.model.domain.Event does exist
> because content.domain['startDate'] works!
> How can we get around this because in a dynamic application like ours we
> don't have the luxury of doing
> content.domain.startDate/content.domain['startDate'] because we don't know
> what the property name is at .page creation.
> Any help would be greatly appreciated.
> Thanks in advance
> Howard
>
>
> --
> This email and any files transmitted with it are confidential and proprietary
> to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received
> in error, use is prohibited. Please destroy, and notify sender. Sender does
> not waive confidentiality or privilege. Internet communications cannot be
> guaranteed to be timely, secure, error or virus-free. Algorithmics does not
> accept liability for any errors or omissions. Any commitment intended to bind
> Algorithmics must be reduced to writing and signed by an authorized signatory.
> --
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Solving the T5 Documentation Dilemma
I'll look into all that. On Tue, May 12, 2009 at 12:06 AM, Ben Gidley wrote: > I think the wiki is a great idea > I was just thinking of adding some notes to it but I can't figure out where > to add them at http://tapestry.formos.com/wiki/dashboard.action. > > It could do with a home page helping people find which space to use etc. > > Would it also be possible to update the Apache wiki home page with a note > saying look at tapestry 360? > > Also I think the permissions are a bit broken as anonymous users can't see > the 'Import from the Apache Wiki' space. > > Ben Gidley > > www.gidley.co.uk > b...@gidley.co.uk > > > On Fri, May 8, 2009 at 9:50 AM, Sergey Didenko > wrote: > >> -1 for forums >> >> +1 for wiki >> >> Wiki is much better to create "persistent" knowledge, imho. >> >> We can try it open for guests thus it would be easier to start for >> occasional users. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Component won't render its body
Hi,
check that the associated .tml is really named correctly and is part of the
correct package. The case matters, it must be same in .java as it is in
.tml. The tml file is not mandatory, if it is omitted then the component
outputs only what the java class writes directly to the writer.
- Ville
daniel joyce wrote:
>
> The component is in a subpackage projects under components,
>
> I use it via
> I know it IS getting picked up ( at the class is ) because the debug
> statements are getting logged. But the tml doesn't render AT ALL.
>
> On Tue, May 12, 2009 at 8:30 AM, daniel joyce
> wrote:
>> I have a method in the java file annotated with @SetupRender. Debug
>> statements show it should be rendering. The code is being called. But
>> no content is emitted by the .tml
>>
>> > xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
>>
>>
>>
>> ${cName}
>>
>>
>>
>>
>>
>>
>> ${pName}
>>
>>
>>
>>
>>
>>
>>
>>
>> Edit
>> Delete
>>
>>
>>
>>
>> At the bare minimum, it should be emitting a empty table into the
>> completed page. Is there another method I need to implement? Something
>> I am missing?
>>
>> I've tried having the method annotated with @SetupRender return void
>> and true; No content at all is emitted by the tml file in either case.
>>
>>
>> -Daniel
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Component-won%27t-render-its-body-tp23504925p23505797.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Debug using maven from IntelliJ IDEA on Mac
I have been facing this problem today and have found a solution to it. I am using IntelliJ 8.1 EAP. I have simply downloaded Maven 2.1.0, installed it locally. When creating a Maven task, in the General tab, one can override the Default Maven Home and that's where you put the location of your maven directory. And that's it, doing that I can now debug my JSF application using jetty:run ;) Hope that helps moritzgilsdorf-2 wrote: > > > Hi, > > I have troubles starting and debugging my apps using IntelliJ and maven. > It > looks like maven is trying to resolve environment variables with "env", > which is installed in /usr/bin . > > I get the following exception: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/bin/java > -Dclassworlds.conf=/usr/local/apache-maven-2.0.9/bin/m2.conf > -Dmaven.home=/usr/local/apache-maven-2.0.9 -Dfile.encoding=MacRoman > -classpath /usr/local/apache-maven-2.0.9/boot/classworlds-1.1.jar > org.codehaus.classworlds.Launcher --no-plugin-registry --fail-fast > --no-plugin-updates --strict-checksums -f /Users/moritz/myapp/pom.xml > jetty:run > Error getting environment vars for profile activation: > java.io.IOException: > env: not found > [WARNING] Failed to initialize environment variable resolver. Skipping > environment substitution in settings. > [WARNING] Failed to initialize environment variable resolver. Skipping > environment substitution in settings. > + Enabling strict checksum verification on all artifact downloads. > --- > constituent[0]: > file:/usr/local/apache-maven-2.0.9/lib/maven-2.0.9-uber.jar > --- > java.io.IOException: env: not found > at java.lang.UNIXProcess.forkAndExec(Native Method) > at java.lang.UNIXProcess.(UNIXProcess.java:52) > at java.lang.ProcessImpl.start(ProcessImpl.java:91) > at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) > at java.lang.Runtime.exec(Runtime.java:591) > at java.lang.Runtime.exec(Runtime.java:429) > at java.lang.Runtime.exec(Runtime.java:326) > at > hidden.org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:250) > at > hidden.org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:216) > at > org.apache.maven.project.interpolation.RegexBasedModelInterpolator.(RegexBasedModelInterpolator.java:63) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at java.lang.Class.newInstance0(Class.java:350) > at java.lang.Class.newInstance(Class.java:303) > at > org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44) > at > org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > at > org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129) > at > org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73) > at > org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68) > at > org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > at > org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129) > at > org.codehaus.plexus.component.composition.FieldComp
Re: Component won't render its body
Found the problem.
5.0.18 can't look up components of the form foo.fooSomeExtension
So my component was called
project.ProjectCompilerConfigView.(tml|java) under components, and
taps couldn't find the tml file. Called the java code, but the tml
file never rendered.
When I changed it to project.CompilerConfigView, it started rendering
the template.
So the 'autotrimming' doesn't seem to work reliably.
On Tue, May 12, 2009 at 8:34 AM, daniel joyce wrote:
> The component is in a subpackage projects under components,
>
> I use it via
> I know it IS getting picked up ( at the class is ) because the debug
> statements are getting logged. But the tml doesn't render AT ALL.
>
> On Tue, May 12, 2009 at 8:30 AM, daniel joyce
> wrote:
>> I have a method in the java file annotated with @SetupRender. Debug
>> statements show it should be rendering. The code is being called. But
>> no content is emitted by the .tml
>>
>> http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
>>
>>
>>
>> ${cName}
>>
>>
>>
>>
>>
>>
>> ${pName}
>>
>>
>>
>>
>>
>>
>>
>>
>> Edit
>> Delete
>>
>>
>>
>>
>> At the bare minimum, it should be emitting a empty table into the
>> completed page. Is there another method I need to implement? Something
>> I am missing?
>>
>> I've tried having the method annotated with @SetupRender return void
>> and true; No content at all is emitted by the tml file in either case.
>>
>>
>> -Daniel
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Component won't render its body
The component is in a subpackage projects under components,
I use it via wrote:
> I have a method in the java file annotated with @SetupRender. Debug
> statements show it should be rendering. The code is being called. But
> no content is emitted by the .tml
>
> http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
>
>
>
> ${cName}
>
>
>
>
>
>
> ${pName}
>
>
>
>
>
>
>
>
> Edit
> Delete
>
>
>
>
> At the bare minimum, it should be emitting a empty table into the
> completed page. Is there another method I need to implement? Something
> I am missing?
>
> I've tried having the method annotated with @SetupRender return void
> and true; No content at all is emitted by the tml file in either case.
>
>
> -Daniel
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Component won't render its body
I have a method in the java file annotated with @SetupRender. Debug
statements show it should be rendering. The code is being called. But
no content is emitted by the .tml
http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
${cName}
${pName}
Edit
Delete
At the bare minimum, it should be emitting a empty table into the
completed page. Is there another method I need to implement? Something
I am missing?
I've tried having the method annotated with @SetupRender return void
and true; No content at all is emitted by the tml file in either case.
-Daniel
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Ognl issues in tapestry 4.1.6
Hi
Ognl in 4.1.6 is behaving rather strangely(I believe this must be a bug)! We're
trying to upgrade from 4.0.2.
Here's a simplified version of what's happening in an insert component.
value="ognl:content.domain['startDate']" renders correctly however
value="ognl:content.domain[sharedPickerProperty]" where sharedPickerProperty is
a property of the page and has initial-value="literal:startDate" results in
org.apache.tapestry.services.impl.HiveMindExpressionCompiler]
context=/opvantage - Error generating OGNL getter for expression
content.domain[sharedPickerProperty] with root $domainbase...@3c1[edit:Event]
and body:
{ return
((com.algorithmics.opvantage.model.domain.Event)(($DomainBase_42)$2).getContent().getDomain()).getStartDate();}
org.apache.hivemind.ApplicationRuntimeException: Unable to add method
java.lang.Object get(ognl.OgnlContext, java.lang.Object) to class
$ASTChain_121354aa5aa: [source error] no such class:
com.algorithmics.opvantage.model.domain.Event
Now obviously com.algorithmics.opvantage.model.domain.Event does exist because
content.domain['startDate'] works!
How can we get around this because in a dynamic application like ours we don't
have the luxury of doing content.domain.startDate/content.domain['startDate']
because we don't know what the property name is at .page creation.
Any help would be greatly appreciated.
Thanks in advance
Howard
--
This email and any files transmitted with it are confidential and proprietary
to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received
in error, use is prohibited. Please destroy, and notify sender. Sender does not
waive confidentiality or privilege. Internet communications cannot be
guaranteed to be timely, secure, error or virus-free. Algorithmics does not
accept liability for any errors or omissions. Any commitment intended to bind
Algorithmics must be reduced to writing and signed by an authorized signatory.
--
Re: T5: Passing named/structured-type params in URLs?
Joel Halbert wrote: > There was a jira feature request raised for named params some time ago: > https://issues.apache.org/jira/browse/TAP5-264 > > > Andy - in the meantime, another alternative is to create a custom > ValueEncoder for activation contexts which can encode and decode a map. > You could then encode the map context using a scheme which uses, for > example, underscores as delimiters, such as: > > /mypage/name1_value1_name2_value2 > (i.e. /mypage/) > > This would allow you to access params by name from an activation > context. > > This works well enough so long as you do not care about using the > correct http request syntax for query strings > (?name1=value1&name2=value2). I've ended up essentially doing this, but more manually via the onActivate() method of the page. Can you point me at any documentation on how to do this with a custom ValueEncoder as you've suggested, and what the benefits would be of doing it that way? (e.g. would this make it easy to use the same param value encoding scheme on multiple pages?) Cheers, Andy -- Dr Andy Buckley Institute for Particle Physics Phenomenology Durham University 0191 3343798 | 0191 3732613 | www.insectnation.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Robert Zeigler wrote: > That should work. > I think it could be interesting, though, if tapestry provided an > additional persistence mechanism, ala: > > @Persist(PersistenceConstants.QUERY_PARAMETER) > private String p; > > @Persist(PersistenceConstants.QUERY_PARAMETR) > private Integer irn; > > which would then take the values in p and irn and stash them in the url, > like: > p=&irn= That sounds nice. I've managed to use a variant of the other suggestion with reasonable results, though, so it now works for me. Thanks. I do have another question about ActionLinks and URL params/context being passed to event handlers, so if you're still feeling helpful then feel free to chip in elsewhere on the thread ;) Cheers, Andy -- Dr Andy Buckley Institute for Particle Physics Phenomenology Durham University 0191 3343798 | 0191 3732613 | www.insectnation.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Thiago H. de Paula Figueiredo wrote:
> Em Fri, 08 May 2009 17:39:07 -0300, Andy Buckley
> escreveu:
>
>> So, is there a Tapestry meachnism for doing something like this? I can
>> do it right now, but I'd rather not have to fight the system. I would
>> expect Tapestry to do it a bit prettier than what I've shown, maybe
>> *something* like
>> .../view/irn/12349876/d/1,2,4
>> (yes, there are issues with telling what's a param name and what's a
>> value... I just mean this schematically) But right now I don't even
>> know where to start looking! Help, please!? ;)
>
> Just use a List as the activation context value. For each named
> parameter one want, add the name first, the value second.
> The above URL would be constructed by Tapestry if you returned a List
> populated like this:
>
> List list = new ArrayList();
> list.add("irn");
> list.add(1245569);
> list.add("d");
> list.add("1,2,4");
>
> Then, declare a onActivate(EventContext context) method and reconstruct
> the pairs:
>
> for (int i = 0; i < context.getCount() / 2; i++) {
> String name = context.get(String.class, i * 2);
> String value = context.get(String.class, i * 2 + 1) // instead of
> String, you could use any type here
> }
Thanks: I've opted to use something similar to this, but with regex
matching instead of twice as many "directory" levels as expected, e.g.
decoding URLs like
.../view/irn1245569/d1,2,4/x1
in the obvious way. Seems to work fairly well so far, so thanks for the
pointer.
This has sparked an extra question, though: I also want to be able to
render my data records in several different ways, i.e. nice HTML tables
by default, but also structured plain text, XML, plotting code and other
formats on demand. Like the main page, these should be accessible via
the URL. So far, I've been using event handlers, e.g.
.../view:xml?irn=1245569&d=1
to call a View.onXML() method. In moving to this new regexy context
encoding, I tried using ActionLinks to make these alternative-format
links, but it doesn't pass the parameters as expected: I have to add an
"@OnEvent(component="xml")" annotation to the onXML() method for it to
work at all, and when I do that the ActionLink uses a dot in the URL
rather than a colon, and ignores the context. I assume there's some
session magic going on to make it work at all, but it means that the
alternative formats can't be accessed via URLs. If I explicitly build
the URL with the context used before, e.g.
.../view.xml/irn1245569/d1
then I get an exception. Is there a way that I can keep using event
handlers for alternative formats and still pass the context params in
the URL? I'd rather not have to split all these formats off into
separate pages, since each contains relatively little logic and the
context decoding seems best defined in the page class (not least for
class reloading convenience.) Looking forward to more useful answers ;)
By the way, T5 developers, it would be nice if the EventContext was
Iterable, so the old-style for-loop can be replaced with
something more Java 5+ish like "for (String s : context) { ..." for
those who just want strings back from the URL context. But that's a
minor, minor point! ;)
Thanks again,
Andy
--
Dr Andy Buckley
Institute for Particle Physics Phenomenology
Durham University
0191 3343798 | 0191 3732613 | www.insectnation.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
[T4]CascadingDropDown component rewind problem?
hi everyone!! i am using a cascading drop down component in my html form,but when i submit form i got the exception like this, Rewind of form test/TabTest$TablePage.$Form expected allocated id #3 to be 'parentId_0', but was 'childId' (requested by component test/TabTest/$DynamicPropertySelection_0). who can tell me the reason of this exception,i still not understand the rewind quite well,thanks a lot!! 2009-05-12 oliverlee000
Re: Upgrade from T4 to T5.1
We're in a similar situation and the same history. Recently I did a little work on mixing new Tap5 pages with an older Tap4 app. It works but it feels a bit awkward and we haven't acid-tested it in production. I'd be interested in your results if you try it. Basically I deployed the new Tap5 pages as a separate app. For example, let's say we have an old app deployed (in JBoss) as oldapp.war and the new pages are deployed as newapp.war. The two apps coexist peacefully in the same server instance, as you'd expect for any two web-apps in the same server. The only communication between the two is through the page URLs. If the old app's menus want to link to one of the new pages, it uses /newapp/page. Note that there's no tight coupling between the two sets of pages, no setting of objects from one to the other. That's okay with us because the new-page development would represent a fairly independent new section. Some limited passing of state could be done in the URL. The awkward bit was sharing lower-level components and libraries that we'd already written. Of course any Tapestry components (such as a border component) have to be rewritten. This is the main reason why we haven't tested this in production; we've written quite a few components. As for the lower-level jars, they're shared because they're deployed independently and not packaged in either app's war. (For my experiment I simply removed them from newapp.war after building it with 'mvn package'.) We had good separation between our model and view layers, so the new app was able to share the same model library. My test had no problem sharing the same (Cayenne) configuration. There were no database staleness issues caused by one app updating the database behind the other's back. There were some other details. Both apps do their own auto-logins from the same cookie, to avoid single-login issues. Logging was a little messy. Tapestry 5 has taken on responsibility for logging configuration, while our old apps let JBoss do it; I often got double-decorated log messages until I simplified the configurations and wrote a custom log4j appender. Hope this helps. On Mon, May 11, 2009 at 3:29 AM, Henrik Schlanbusch wrote: > Hi all > > We have a rather big system that has been written in tapestry 4. We started > out > in tapestry 3 some years ago and during upgrade to T4 we spent quite a long > time, which was very critical for our customers. But in the end, the > upgrade was > really worth it. > > Now we would like to upgrade to T5.1. I know about the backwards > compatibility > issues here, so what I would like to do is to upgrade "lazily". What I > would > like to do is to run T4 and T5 at the same time, while we develop new stuff > in > T5, and slowly transform old T4 functionality to T5. > > So my question is: is it possible to run T4 and T5 from the same webapp? > And if > it does, what is the best practice in order to do so? > > Best regards > Henrik > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: t5: upgrading from 5.0.18 to 5.1.0.5
On Tue, May 12, 2009 at 12:46 AM, Angelo Chen wrote: > if i uncomment the script referring to jquery below, the two errors will go > away, then, how to include jquery in the tml? thanks Hi! Both Prototype (used by Tapestry internally) and jQuery define a $() function. To use both without jQuery messing up Prototype, take a look at this page: http://docs.jquery.com/Using_jQuery_with_Other_Libraries. -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Composite form components
When creating sub-form components I find that a common case is composing several form fields into a single object which is bound as a parameter back to the parent. For example a date component used on several forms that has drop downs for day & month, and a text box for year. The parameter bound to the parent page is simply a date (a Date object or a String form - doesn't matter) which is composed from the three separate form elements. The only way I know of to support this is to used the setter for the last form element's property to set the bound parameter with the composed object. (this is the technique used in the T5 book) This works okay, but I've never been very happy with it and recently it meant that I had to copy a component class to extend it because of using this technique. This is because the properties are private (T5 requires this) and the setter for one has a side effect that causes problems. This got me to thinking (again) if there was an alternative technique for achieving this, and if there wasn't then how could it potentially be done. So, does anyone currently have a better way than the one I've described? I was thinking that this could potentially be achieved by another component event as part of the form submission. Each component within the form (not just the parent of the form) would need an event firing after the properties have all been set from the submission, and before validation, where they could update bound parameters with composed objects from the form properties. Is this at all possible to achieve? Thanks, Andy.
Re: Benchmarking Tapestry
There is no point in agreeing or disagreeing it basically depends on your use case. I know applications staying 200 ms in the database layer, in that case rendering is normally a non issue. But if your database layer is using a cache and the data is available in 2 ms, then of course rendering plays a role. When evaluating the frameworks in my articles, I try to setup a kind of realistic page for a Get and Post request with and without templates and a realistic application. I measure both performance with a single thread and scalability with increasing number of threads and monitor the garbage collection to finally proper evaluate the performance. A main problem is that the servers are pretty fast and you have to make sure that the client nore the network is saturated. I setup the server in a virtual machine and create load from a separated machine, both connected with a quality GigaBit switch - no home hardware. Getting reasonable numbers is far from simple. I have not yet finished by Tapestry evaluation, but hopefully this month, I will complete it. -- Best Regards / Viele Gruesse Sebastian Hennebrueder --- Training for Java Persistence and Hibernate - http://www.laliluna.de Ben Gidley schrieb: I do disagree :) For example my tests are showing tapestry work taking (even on worst cases) <20ms - however I can easily on production web apps get page renders in 300-500 ms. When you look what is happening it is all the data loading/preparation done outside of the web framework. My point was therefore in the real world I focus on getting that code efficient - as I get more bang for my buck! The key bottleneck is usually database access. So you tend to have to cache/optimise queries. I also tend to spend a lot of time on the YSlow ( http://developer.yahoo.com/performance/rules.html) recommendations as these can make a huge difference to perceived render time. Now tapestry has auto-assembled javascripts that should make a substantial increase in percieved render time. Ben Gidley www.gidley.co.uk b...@gidley.co.uk On Tue, May 12, 2009 at 8:53 AM, Peter Stavrinides < p.stavrini...@albourne.com> wrote: 90% of the time will be spent in your code (e.g. accessing the db) and not in the framework. Simply not true, Data retrieval is very fast, unless your are doing some serious number crunching, more time is spent rendering (especially the DOM which is notoriously slow). Peter - Original Message - From: "Howard Lewis Ship" To: "Tapestry users" Sent: Tuesday, 12 May, 2009 02:00:50 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry On Mon, May 11, 2009 at 12:10 PM, Thiago H. de Paula Figueiredo wrote: Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon escreveu: Tapestry 5.0.18: I missed this earlier; yes, 5.0.18 had not yet been optimized for memory or speed. Anything in the 5.1, preferable 5.1.0.5 the stable release, would perform better. Requests per second:776 Average resp time (ms): 25.41075 Have you tried Tapestry 5.1.0.5? There were some improvements in the rendering process starting at 5.1.0.1. Another issue is to have the same machine being the client and the server and the number of concurrent threads. The best scenario is having one machine as the server and N others as the clients, because you don't have threads in the same machine trying to use the same shared resource (the network stack and adapter). By the way, I have a little of benchmarking experience and all the hints given by Christian are absolutely correct. -- Thiago H. de Paula Figueiredo Consultor, desenvolvedor e instrutor em Java http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: t5: forwarding in index
Borut Bolčina wrote: So it is not AuthenticationProcessingFilter responsible for taking control of the authentication because the form posts to j_spring_security_check url. I misunderstood your initial posting. Because I set action to the AuthenticationProcessingFilter URL Spring handles my authentication but that's not what you want. I can think of two possible solutions. 1). Create a non-Tapestry form (like I do) but hidden and post this form with javascript. This requires Javascript so I'm not sure if you want to use this 2) Replicate AuthenticationProcessingFilter's behavior (See org.springframework.security.ui.webapp.AuthenticationProcessingFilter). You'll need to inject some Spring instances into your Tapestry components. Martijn Brinkers How does your "Check" page look like? Are you using the authenticate method of the AbstractUserDetailsAuthenticationProvider? Thanks, Borut 2009/4/16 martijn.list no I do not have any information, sadly. I had to ditch the concept of having tapestry form together with tapestry-spring-security. Perhaps I misunderstand what you are trying to do but I do have a Tapestry form that uses Spring security to authenticate the user. My form looks like: Name Your user name Password required Login in spring.xml I'm not sure whether tapestry-spring-security supports this but using Spring security directly does. Regards, Martijn Brinkers -- Djigzo open source email encryption www.djigzo.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Djigzo open source email encryption gateway www.djigzo.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Benchmarking Tapestry
You mentioned this, which threw me off: >The key bottleneck is usually database access. So you tend to have to >cache/optimise queries. So I assumed you were referring to data as purely 'data' from a database. Peter - Original Message - From: "Peter Stavrinides" To: "Tapestry users" Sent: Tuesday, 12 May, 2009 13:43:21 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry > Um, data retrieval is usually made across a network connection, even > to the localhost, it's still likely to add up more latency than > rendering in-memory. Apologies Ben, now I understand what you meant, you are inferring data to be = resource retrieval (all assets etc.) with page and DOM rendering... I don't dispute that. Kind regards, Peter Maybe not 99/1, but I think Howard was being a bit hyperbolic, but in my experience, at least 2/1, and usually more like 5/1. Otherwise, we wouldn't put so much effort into caching strategies against persistence layers, etc. cheers, Christian. -- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. - Original Message - From: "Christian Edward Gruber" To: "Tapestry users" Sent: Tuesday, 12 May, 2009 11:07:21 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry Um, data retrieval is usually made across a network connection, even to the localhost, it's still likely to add up more latency than rendering in-memory. Maybe not 99/1, but I think Howard was being a bit hyperbolic, but in my experience, at least 2/1, and usually more like 5/1. Otherwise, we wouldn't put so much effort into caching strategies against persistence layers, etc. cheers, Christian. On 12-May-09, at 03:53 , Peter Stavrinides wrote: >> 90% of the time will be spent in your code (e.g. accessing the db) >> and not in the framework. > Simply not true, Data retrieval is very fast, unless your are doing > some serious number crunching, more time is spent rendering > (especially the DOM which is notoriously slow). > > Peter > > - Original Message - > From: "Howard Lewis Ship" > To: "Tapestry users" > Sent: Tuesday, 12 May, 2009 02:00:50 GMT +02:00 Athens, Beirut, > Bucharest, Istanbul > Subject: Re: Benchmarking Tapestry > > On Mon, May 11, 2009 at 12:10 PM, Thiago H. de Paula Figueiredo > wrote: >> Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon > > >> escreveu: >> >>> Tapestry 5.0.18: > > I missed this earlier; yes, 5.0.18 had not yet been optimized for > memory or speed. Anything in the 5.1, preferable 5.1.0.5 the stable > release, would perform better. > >>> Requests per second:776 >>> Average resp time (ms): 25.41075 >> >> Have you tried Tapestry 5.1.0.5? There were some improvements in the >> rendering process starting at 5.1.0.1. >> >> Another issue is to have the same machine being the client and the >> server >> and the number of concurrent threads. The best scenario is having one >> machine as the server and N others as the clients, because you >> don't have >> threads in the same machine trying to use the same shared resource >> (the >> network stack and adapter). >> >> By the way, I have a little of benchmarking experience and all the >> hints >> given by Christian are absolutely correct. >> >> -- >> Thiago H. de Paula Figueiredo >> Consultor, desenvolvedor e instrutor em Java >> http://www.arsmachina.com.br/thiago >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > Director of Open Source Technology at Formos > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > Christian Edward Gruber e-mail: christianedwardgru...@gmail.com weblog: http://www.geekinasuit.com/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Benchmarking Tapestry
> Um, data retrieval is usually made across a network connection, even > to the localhost, it's still likely to add up more latency than > rendering in-memory. Apologies Ben, now I understand what you meant, you are inferring data to be = resource retrieval (all assets etc.) with page and DOM rendering... I don't dispute that. Kind regards, Peter Maybe not 99/1, but I think Howard was being a bit hyperbolic, but in my experience, at least 2/1, and usually more like 5/1. Otherwise, we wouldn't put so much effort into caching strategies against persistence layers, etc. cheers, Christian. -- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. - Original Message - From: "Christian Edward Gruber" To: "Tapestry users" Sent: Tuesday, 12 May, 2009 11:07:21 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry Um, data retrieval is usually made across a network connection, even to the localhost, it's still likely to add up more latency than rendering in-memory. Maybe not 99/1, but I think Howard was being a bit hyperbolic, but in my experience, at least 2/1, and usually more like 5/1. Otherwise, we wouldn't put so much effort into caching strategies against persistence layers, etc. cheers, Christian. On 12-May-09, at 03:53 , Peter Stavrinides wrote: >> 90% of the time will be spent in your code (e.g. accessing the db) >> and not in the framework. > Simply not true, Data retrieval is very fast, unless your are doing > some serious number crunching, more time is spent rendering > (especially the DOM which is notoriously slow). > > Peter > > - Original Message - > From: "Howard Lewis Ship" > To: "Tapestry users" > Sent: Tuesday, 12 May, 2009 02:00:50 GMT +02:00 Athens, Beirut, > Bucharest, Istanbul > Subject: Re: Benchmarking Tapestry > > On Mon, May 11, 2009 at 12:10 PM, Thiago H. de Paula Figueiredo > wrote: >> Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon > > >> escreveu: >> >>> Tapestry 5.0.18: > > I missed this earlier; yes, 5.0.18 had not yet been optimized for > memory or speed. Anything in the 5.1, preferable 5.1.0.5 the stable > release, would perform better. > >>> Requests per second:776 >>> Average resp time (ms): 25.41075 >> >> Have you tried Tapestry 5.1.0.5? There were some improvements in the >> rendering process starting at 5.1.0.1. >> >> Another issue is to have the same machine being the client and the >> server >> and the number of concurrent threads. The best scenario is having one >> machine as the server and N others as the clients, because you >> don't have >> threads in the same machine trying to use the same shared resource >> (the >> network stack and adapter). >> >> By the way, I have a little of benchmarking experience and all the >> hints >> given by Christian are absolutely correct. >> >> -- >> Thiago H. de Paula Figueiredo >> Consultor, desenvolvedor e instrutor em Java >> http://www.arsmachina.com.br/thiago >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > Director of Open Source Technology at Formos > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > Christian Edward Gruber e-mail: christianedwardgru...@gmail.com weblog: http://www.geekinasuit.com/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
t5:How to trigger a client side event after ajax form submit ?
How to trigger a client side event after ajax form submit?For example a ajax login form,redisplay the form when failure . thanks /luna -- View this message in context: http://www.nabble.com/t5%3AHow-to-trigger-a-client-side-event-after-ajax-form-submit---tp23499985p23499985.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Benchmarking Tapestry
On Tue, May 12, 2009 at 10:02 AM, Ben Gidley wrote: > I do disagree :) Very nice and very interesting work Ben! Thanks a lot for sharing. Regards -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Benchmarking Tapestry
Um, data retrieval is usually made across a network connection, even to the localhost, it's still likely to add up more latency than rendering in-memory. Maybe not 99/1, but I think Howard was being a bit hyperbolic, but in my experience, at least 2/1, and usually more like 5/1. Otherwise, we wouldn't put so much effort into caching strategies against persistence layers, etc. cheers, Christian. On 12-May-09, at 03:53 , Peter Stavrinides wrote: 90% of the time will be spent in your code (e.g. accessing the db) and not in the framework. Simply not true, Data retrieval is very fast, unless your are doing some serious number crunching, more time is spent rendering (especially the DOM which is notoriously slow). Peter - Original Message - From: "Howard Lewis Ship" To: "Tapestry users" Sent: Tuesday, 12 May, 2009 02:00:50 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry On Mon, May 11, 2009 at 12:10 PM, Thiago H. de Paula Figueiredo wrote: Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon > escreveu: Tapestry 5.0.18: I missed this earlier; yes, 5.0.18 had not yet been optimized for memory or speed. Anything in the 5.1, preferable 5.1.0.5 the stable release, would perform better. Requests per second:776 Average resp time (ms): 25.41075 Have you tried Tapestry 5.1.0.5? There were some improvements in the rendering process starting at 5.1.0.1. Another issue is to have the same machine being the client and the server and the number of concurrent threads. The best scenario is having one machine as the server and N others as the clients, because you don't have threads in the same machine trying to use the same shared resource (the network stack and adapter). By the way, I have a little of benchmarking experience and all the hints given by Christian are absolutely correct. -- Thiago H. de Paula Figueiredo Consultor, desenvolvedor e instrutor em Java http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org Christian Edward Gruber e-mail: christianedwardgru...@gmail.com weblog: http://www.geekinasuit.com/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Benchmarking Tapestry
I do disagree :) For example my tests are showing tapestry work taking (even on worst cases) <20ms - however I can easily on production web apps get page renders in 300-500 ms. When you look what is happening it is all the data loading/preparation done outside of the web framework. My point was therefore in the real world I focus on getting that code efficient - as I get more bang for my buck! The key bottleneck is usually database access. So you tend to have to cache/optimise queries. I also tend to spend a lot of time on the YSlow ( http://developer.yahoo.com/performance/rules.html) recommendations as these can make a huge difference to perceived render time. Now tapestry has auto-assembled javascripts that should make a substantial increase in percieved render time. Ben Gidley www.gidley.co.uk b...@gidley.co.uk On Tue, May 12, 2009 at 8:53 AM, Peter Stavrinides < p.stavrini...@albourne.com> wrote: > > 90% of the time will be spent in your code (e.g. accessing the db) and > not in the framework. > Simply not true, Data retrieval is very fast, unless your are doing some > serious number crunching, more time is spent rendering (especially the DOM > which is notoriously slow). > > Peter > > - Original Message - > From: "Howard Lewis Ship" > To: "Tapestry users" > Sent: Tuesday, 12 May, 2009 02:00:50 GMT +02:00 Athens, Beirut, Bucharest, > Istanbul > Subject: Re: Benchmarking Tapestry > > On Mon, May 11, 2009 at 12:10 PM, Thiago H. de Paula Figueiredo > wrote: > > Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon > > escreveu: > > > >> Tapestry 5.0.18: > > I missed this earlier; yes, 5.0.18 had not yet been optimized for > memory or speed. Anything in the 5.1, preferable 5.1.0.5 the stable > release, would perform better. > > >> Requests per second:776 > >> Average resp time (ms): 25.41075 > > > > Have you tried Tapestry 5.1.0.5? There were some improvements in the > > rendering process starting at 5.1.0.1. > > > > Another issue is to have the same machine being the client and the server > > and the number of concurrent threads. The best scenario is having one > > machine as the server and N others as the clients, because you don't have > > threads in the same machine trying to use the same shared resource (the > > network stack and adapter). > > > > By the way, I have a little of benchmarking experience and all the hints > > given by Christian are absolutely correct. > > > > -- > > Thiago H. de Paula Figueiredo > > Consultor, desenvolvedor e instrutor em Java > > http://www.arsmachina.com.br/thiago > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > Director of Open Source Technology at Formos > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Benchmarking Tapestry
> 90% of the time will be spent in your code (e.g. accessing the db) and not in > the framework. Simply not true, Data retrieval is very fast, unless your are doing some serious number crunching, more time is spent rendering (especially the DOM which is notoriously slow). Peter - Original Message - From: "Howard Lewis Ship" To: "Tapestry users" Sent: Tuesday, 12 May, 2009 02:00:50 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry On Mon, May 11, 2009 at 12:10 PM, Thiago H. de Paula Figueiredo wrote: > Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon > escreveu: > >> Tapestry 5.0.18: I missed this earlier; yes, 5.0.18 had not yet been optimized for memory or speed. Anything in the 5.1, preferable 5.1.0.5 the stable release, would perform better. >> Requests per second: 776 >> Average resp time (ms): 25.41075 > > Have you tried Tapestry 5.1.0.5? There were some improvements in the > rendering process starting at 5.1.0.1. > > Another issue is to have the same machine being the client and the server > and the number of concurrent threads. The best scenario is having one > machine as the server and N others as the clients, because you don't have > threads in the same machine trying to use the same shared resource (the > network stack and adapter). > > By the way, I have a little of benchmarking experience and all the hints > given by Christian are absolutely correct. > > -- > Thiago H. de Paula Figueiredo > Consultor, desenvolvedor e instrutor em Java > http://www.arsmachina.com.br/thiago > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: t5: forwarding in index
Hi, warming up this thread again... So it is not AuthenticationProcessingFilter responsible for taking control of the authentication because the form posts to j_spring_security_check url. How does your "Check" page look like? Are you using the authenticate method of the AbstractUserDetailsAuthenticationProvider? Thanks, Borut 2009/4/16 martijn.list > no I do not have any information, sadly. I had to ditch the concept of >> having tapestry form together with tapestry-spring-security. >> > > Perhaps I misunderstand what you are trying to do but I do have a Tapestry > form that uses Spring security to authenticate the user. > > My form looks like: > > >Name >Your user name > > > >Password >required > > > >Login > > > > in spring.xml > > > login-page="/login" >authentication-failure-url="/login/failed" >login-processing-url="/check" >always-use-default-target="true"/> > > > > > I'm not sure whether tapestry-spring-security supports this but using > Spring security directly does. > > Regards, > > Martijn Brinkers > > > -- > Djigzo open source email encryption www.djigzo.com > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Solving the T5 Documentation Dilemma
I think the wiki is a great idea I was just thinking of adding some notes to it but I can't figure out where to add them at http://tapestry.formos.com/wiki/dashboard.action. It could do with a home page helping people find which space to use etc. Would it also be possible to update the Apache wiki home page with a note saying look at tapestry 360? Also I think the permissions are a bit broken as anonymous users can't see the 'Import from the Apache Wiki' space. Ben Gidley www.gidley.co.uk b...@gidley.co.uk On Fri, May 8, 2009 at 9:50 AM, Sergey Didenko wrote: > -1 for forums > > +1 for wiki > > Wiki is much better to create "persistent" knowledge, imho. > > We can try it open for guests thus it would be easier to start for > occasional users. > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
