Re: How to write a common propertie files for specific languages.

2013-01-12 Thread Anbazhagan
Thanks for your replay. it's really helpful for me.



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/How-to-write-a-common-propertie-files-for-specific-languages-tp5719254p5719263.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



Can't get Tapestry 5.4-alpha-2 jQuery Support to work

2013-01-12 Thread trsvax
I created a project with alpha-2 in my POM and followed the blog post 

http://tapestryjava.blogspot.com/2013/01/tapestry-54-jquery-support-now-in-place.html

by adding this to my AppModule

   @Contribute(SymbolProvider.class)
@ApplicationDefaults
public static void
contributeApplicationDefaults(MappedConfigurationString, Object
configuration) {
configuration.add(SymbolConstants.SUPPORTED_LOCALES, en);
configuration.add(SymbolConstants.PRODUCTION_MODE, false);
configuration.add(SymbolConstants.APPLICATION_VERSION,
0.0.1-SNAPSHOT);
configuration.add(SymbolConstants.HMAC_PASSPHRASE,test);   
   
configuration.add(SymbolConstants.JAVASCRIPT_INFRASTRUCTURE_PROVIDER,
jquery);
 }

 

@Contribute(Compatibility.class)
public static void disableScriptaculous(MappedConfigurationTrait,
Boolean configuration) {
// not needed with jquery configuration.add(Trait.SCRIPTACULOUS,
false);
configuration.add(Trait.INITIALIZERS, false);
}

Changing the Trait values works as I would expect but no matter what I set
SymbolConstants.JAVASCRIPT_INFRASTRUCTURE_PROVIDER to I still get the
prototype.js and 
t5-core-dom-prototype.js (as dom.js). I set a break point and the code

if (provider.equals(prototype))
{
configuration.add(t5/core/dom, new
JavaScriptModuleConfiguration(domPrototype));
}
 
if (provider.equals(jquery))
{
configuration.add(t5/core/dom, new
JavaScriptModuleConfiguration(domJQuery));
}

appears to do the right thing. Is there something I'm missing?



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-t-get-Tapestry-5-4-alpha-2-jQuery-Support-to-work-tp5719266.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



Session Expiration - Ajax

2013-01-12 Thread Howard Lewis Ship
In Tapestry, individual page and component fields, marked with the @Perist
or @SessionState annotations, will be stored in the the HttpSession.
 Tapestry generates a unique session attribute key that identifies the name
of the page, nested component id, and field name.

If any request, Ajax or otherwise, is received after the session has been
invalidated, Tapestry will simply proceed using default (typically, null)
values for such fields. In some cases, the page may wish to inject the
Request so as to query whether the session is invalidated ... though it may
be easier to see if the specific field is null when it is not expected to
be.

Lance's note about a thread local map is actually a more recent
optimization; once you have the basic infrastructure to intercept field
access so as to store and retrieve data from the HttpSession, you can do
the same trick to separate instances from their state.


On Tue, Jan 8, 2013 at 8:54 PM, Shaun Thompson
stho...@gmail.comjavascript:_e({}, 'cvml', 'stho...@gmail.com');
 wrote:

 I'm currently evaluating component based frameworks, as we are using
 Wicket, and one of the problems we encounter is Ajax interactions after the
 http session has expired.

 If a user clicks on a component that is Ajax enabled - the framework throws
 a PageExpiration exception.

 For most applications, we want the request to still continue.

 The HelloWorld example from Tapestry doesn't appear to experience this.

 My questions are

 - For persistent data on a page where is this serialized to?
 - Are all Ajax interactions safe in this manner, form buttons, links, etc




-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

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

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


-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

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

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


Re: Can't get Tapestry 5.4-alpha-2 jQuery Support to work

2013-01-12 Thread Serge Eby
Hi,

For 5.4-alpha-2, I believe you still need to disable Scriptaculous when
using JQuery (it's fixed in alpha-3).

I see that you commented out this line:

// not needed with jquery configuration.add(Trait.SCRIPTACULOUS,
false); 

Is it not working when uncommented?



/Serge




--
View this message in context: 
http://tapestry-users.832.n2.nabble.com/Can-t-get-Tapestry-5-4-alpha-2-jQuery-Support-to-work-tp7584477p7584479.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: Can't get Tapestry 5.4-alpha-2 jQuery Support to work

2013-01-12 Thread trsvax
I commented out the line to see if the the jquery line was working. The
Scriptaculous Trait only applies for prototype and that's exactly what
happens. If I set 

SymbolConstants.JAVASCRIPT_INFRASTRUCTURE_PROVIDER,jquery 

the Scriptacolous trait does nothing. With

SymbolConstants.JAVASCRIPT_INFRASTRUCTURE_PROVIDER,prototype 

Scriptaculous is turned on and off.




--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-t-get-Tapestry-5-4-alpha-2-jQuery-Support-to-work-tp5719266p5719269.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: Session Expiration - Ajax

2013-01-12 Thread Lenny Primak
I think that this area is where Tapestry actually needs usability improvement.
Usually, with setupRender() doing all the initialization, when Ajax request gets
called (much) later with an invalidated session, all sorts of NPEs would result.
Of course this can be solved with onActivate() or null checks, but usually the 
best
solution is just to redirect to the same page, and 'redraw' the page in a 
non-ajax way
to re-initialize everything.  If the page is protected by a login screen, the 
login screen redirection
should result.
This is fixed in the FlowLogix library, but I think stock Tapestry needs to 
incorporate this.
FlowLogix @AJAX annotation / supporting code does this currently.

On Jan 12, 2013, at 11:10 AM, Howard Lewis Ship wrote:

 In Tapestry, individual page and component fields, marked with the @Perist
 or @SessionState annotations, will be stored in the the HttpSession.
 Tapestry generates a unique session attribute key that identifies the name
 of the page, nested component id, and field name.
 
 If any request, Ajax or otherwise, is received after the session has been
 invalidated, Tapestry will simply proceed using default (typically, null)
 values for such fields. In some cases, the page may wish to inject the
 Request so as to query whether the session is invalidated ... though it may
 be easier to see if the specific field is null when it is not expected to
 be.
 
 Lance's note about a thread local map is actually a more recent
 optimization; once you have the basic infrastructure to intercept field
 access so as to store and retrieve data from the HttpSession, you can do
 the same trick to separate instances from their state.
 
 
 On Tue, Jan 8, 2013 at 8:54 PM, Shaun Thompson
 stho...@gmail.comjavascript:_e({}, 'cvml', 'stho...@gmail.com');
 wrote:
 
 I'm currently evaluating component based frameworks, as we are using
 Wicket, and one of the problems we encounter is Ajax interactions after the
 http session has expired.
 
 If a user clicks on a component that is Ajax enabled - the framework throws
 a PageExpiration exception.
 
 For most applications, we want the request to still continue.
 
 The HelloWorld example from Tapestry doesn't appear to experience this.
 
 My questions are
 
 - For persistent data on a page where is this serialized to?
 - Are all Ajax interactions safe in this manner, form buttons, links, etc
 
 
 
 
 -- 
 Howard M. Lewis Ship
 
 Creator of Apache Tapestry
 
 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!
 
 (971) 678-5210
 http://howardlewisship.com
 
 
 -- 
 Howard M. Lewis Ship
 
 Creator of Apache Tapestry
 
 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!
 
 (971) 678-5210
 http://howardlewisship.com


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