Re: Page components are not loaded in JBoss
Rakesh,
I don't have time to debug your problem but I can offer you a working project
and packaging/deployment instructions to compare to: JumpStart is developed
with Jetty and the demo is deployed on JBoss 7.1.1. Here is the demo:
http://jumpstart.doublenegative.com.au/jumpstart/
The step-by-step instructions are on the Tips page in Other servers JBoss 7.1:
http://jumpstart.doublenegative.com.au/jumpstart6.7/tips.html
HTH,
Geoff
On 10/03/2013, at 5:07 AM, rakcheru wrote:
Tapestry version : 5.3.6
Jboss : 7.1.1
Greetings,
I had been struggling for most of the day trying to make tapestry run on
jboss 7.1.1
Issue:
The page components are not at all working. Even the default page
components are not loaded
The same app is working fine in jetty
Things i tried:
Gone through the wiki articles about overriding ClasspathURLConverter but
couldnt make it work. Issue : no matter what i do, the AppModule is not
LOADED at all. Steps followed:
1. Added a new ClasspathURLConverter subclass in the project
2. Placed AppModule.java under tapestry.app-package.services package
3. AppModule.java holds a method
public static void
contributeServiceOverride(MappedConfigurationClass, Object configuration) {
configuration.add(ClasspathURLConverter.class, new
JBoss711ClasspathURLConverter());
}
Things observed:
When compared the log data from jetty to that of jboss, seems like
ComponentClassResolver is not invoked in jboss
jetty:
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.ioc.services.TapestryIOCModule
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.json.services.JSONModule
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.services.TapestryModule
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.internal.services.InternalModule
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.services.assets.AssetsModule
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.services.pageload.PageLoadModule
[WARN] TapestryFilter Application Module class
com.rakesh.demotapestry.web.services.TapestryModule not found
[DEBUG] TapestryModule.ComponentClassResolver Creating proxy for
service ComponentClassResolver
[DEBUG] TapestryModule.ComponentClassResolver Constructing service
implementation via
org.apache.tapestry5.services.TapestryModule.buildComponentClassResolver(ComponentClassResolverImpl,
InvalidationEventHub) (at TapestryModule.java:1213)
jboss:
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.ioc.services.TapestryIOCModule
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.json.services.JSONModule
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.services.TapestryModule
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.internal.services.InternalModule
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.services.assets.AssetsModule
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.services.pageload.PageLoadModule
WARN TapestryFilter] Application Module class
com.rakesh.demotapestry.web.services.TapestryModule not found
INFO TapestryFilter] Startup status:
Any help greatly appreciated.
Thanks in advance,
Rakesh
-
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: First stab at CDI module for tapestry
Kalle, that is exactly correct.
The CDI stuff (and by extension the CDI code in FlowLogix) which is taken
direct from CDI module
is so meant to use CDI beans in Tapestry, not use Tapestry services as CDI
beans.
On Mar 10, 2013, at 1:58 AM, Kalle Korhonen wrote:
Both of these seem to be about referencing and using CDI managed beans in
Tapestry services, please correct me if I'm wrong. What I'm asking is the
reverse - using Tapestry services in applications frameworks expecting a
CDI environment.
Kalle
On Sat, Mar 9, 2013 at 3:41 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote:
Actually, the CDI SPI statement may not be accurate.
CDI support uses BeanManager to do its job, so its CDI SPI. Not sure,
Kalle, if that's what you are referring to.
http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/web/services/CDIModule.java
On Mar 9, 2013, at 5:56 PM, Lenny Primak wrote:
I would love to contribute the FlowLogix module, or as much of it as it
still applies to tapestry 5.4 into the core. It includes CDI support plus
the JEE stack support.
The CDI interface doesn't use SPI yet.
On Mar 9, 2013, at 5:34 PM, Kalle Korhonen kalle.o.korho...@gmail.com
wrote:
Hey Magnus,
as part of your tapestry-cdi work, did you look into implementing a
Tapestry CDI SPI, i.e. an implementation of
javax.enterprise.inject.spi.BeanManager? This is related to my earlier
thread about injectable entitylisteners (
http://mail-archives.apache.org/mod_mbox/tapestry-dev/201210.mbox/%3CCA+=ewnb+tjv01fiyzsded3u5iyop3wcf1r3prhqtdjrm7ix...@mail.gmail.com%3E
).
JPA 2.1 is required the check the SPI (see
http://java.dzone.com/articles/cdi-extensions-you-can-build,
http://java.net/downloads/jpa-spec/JavaPersistencePFD.pdf,
http://stackoverflow.com/questions/12951701/how-to-get-entity-manager-or-transaction-in-jpa-listener
,
http://stackoverflow.com/questions/11740322/cdi-injection-is-not-working-in-servlets
).
The CDI is a solid spec, we should start thinking about offering
tapestry-cdi or similar as a core Tapestry module.
Kalle
On Thu, Aug 18, 2011 at 11:59 AM, Magnus Kvalheim mag...@kvalheim.dk
wrote:
Yes, I've noticed. Great work Igor :)
I've intentionally not done anything for tapestry-cdi in terms of
supporting
javax.inject.@Inject.
As Tap @inject and javax @inject are interchangeable - cdi bean
injection
with either @inject should 'just work' with tapestry-cdi and T5.3 :)
On Thu, Aug 18, 2011 at 12:56 PM, Igor Drobiazko
igor.drobia...@gmail.comwrote:
Just as a side note: starting with T5.3 it's possible to use JSR 330
for
injection.
Check this out:
http://tapestry.apache.org/using-jsr-330-standard-annotations.html
On Wed, Jun 8, 2011 at 1:56 PM, Magnus Kvalheim mag...@kvalheim.dk
wrote:
Hi all,
We're looking into moving our apps from a 'traditional' servlet
container
with spring into a Java EE web profile server like glassfish 3.1.
Motivations for doing this is to utilize cdi(jsr 299, 330), ejb3 and
more.
Not just for the tapestry app, but also the other applications in
our portfoleo which share common core business logic.
For reference on previous discussions:
http://tapestry.1045711.n5.nabble.com/Java-based-spring-configuration-td3394086.html
http://tapestry.1045711.n5.nabble.com/Discussion-td2421783i20.html
Now, I've tried running the tapestry quickstart app in glassfish 3.1
(with
the eclipse connector for publishing).
This works ok - although I cannot make live class reloading work. :(
Glassfish uses Weld, so the CDIModule is basically an objectprovider
for
injecting Weld managed beans.
(As you probably know CDI/Weld can also be used outside jee as
alternative
to tapestry-ioc, spring, etc)
*CDIModule class*
*public class CDIModule { *
* public static void bind(ServiceBinder binder) {*
*binder.bind(ObjectProvider.class,
CDIObjectProvider.class).withId(CDIObjectProvider);*
*} *
* public static BeanManager buildBeanManager(Logger log) { *
* try {*
* BeanManager beanManager = (BeanManager) new
InitialContext().lookup(java:comp/BeanManager);*
* return beanManager; *
* } catch (NamingException e) {*
* log.error(Could not lookup jndi resource: java:comp/BeanManager,
e);*
* }*
* return null;*
* } *
* public static void contributeMasterObjectProvider(*
* @InjectService(CDIObjectProvider) ObjectProvider cdiProvider,*
* OrderedConfigurationObjectProvider configuration) { *
*// configuration.add(cdiProvider, cdiProvider,
after:Service,after:AnnotationBasedContributions,after:Alias,after:Autobuild);
*
* configuration.add(cdiProvider, cdiProvider, after:*); *
* } *
*}*
*
*
The beanmanager is expected to be found in jndi. If the beans.xml is
present
it will be available at this point.
The BeanManager is also exposed as a service and injectable for other
services or components.
I've tested by adding the
Re: Page components are not loaded in JBoss
[WARN] TapestryFilter Application Module class
com.rakesh.demotapestry.web.services.TapestryModule not found
The above appears in both the Jetty and Jboss log. I would expect your app will
not work in Jetty nor in Jboss.
It looks as though the tapestry filter name in web.xml does not match your
Tapetsry IOC module name.
Please check the doc at
http://tapestry.apache.org/configuration.html#Configuration-Changestoweb.xml
Shing
- Original Message -
From: rakcheru rakch...@gmail.com
To: Tapestry users users@tapestry.apache.org
Cc:
Sent: Saturday, March 9, 2013 6:07 PM
Subject: Page components are not loaded in JBoss
Tapestry version : 5.3.6
Jboss : 7.1.1
Greetings,
I had been struggling for most of the day trying to make tapestry run on jboss
7.1.1
Issue:
The page components are not at all working. Even the default page
components are not loaded
The same app is working fine in jetty
Things i tried:
Gone through the wiki articles about overriding ClasspathURLConverter but
couldnt make it work. Issue : no matter what i do, the AppModule is not LOADED
at all. Steps followed:
1. Added a new ClasspathURLConverter subclass in the project
2. Placed AppModule.java under tapestry.app-package.services package
3. AppModule.java holds a method
public static void
contributeServiceOverride(MappedConfigurationClass, Object configuration) {
configuration.add(ClasspathURLConverter.class, new
JBoss711ClasspathURLConverter());
}
Things observed:
When compared the log data from jetty to that of jboss, seems like
ComponentClassResolver is not invoked in jboss
jetty:
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.ioc.services.TapestryIOCModule
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.json.services.JSONModule
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.services.TapestryModule
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.internal.services.InternalModule
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.services.assets.AssetsModule
[INFO] ioc.RegistryBuilder Adding module definition for class
org.apache.tapestry5.services.pageload.PageLoadModule
[WARN] TapestryFilter Application Module class
com.rakesh.demotapestry.web.services.TapestryModule not found
[DEBUG] TapestryModule.ComponentClassResolver Creating proxy for
service ComponentClassResolver
[DEBUG] TapestryModule.ComponentClassResolver Constructing service
implementation via
org.apache.tapestry5.services.TapestryModule.buildComponentClassResolver(ComponentClassResolverImpl,
InvalidationEventHub) (at TapestryModule.java:1213)
jboss:
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.ioc.services.TapestryIOCModule
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.json.services.JSONModule
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.services.TapestryModule
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.internal.services.InternalModule
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.services.assets.AssetsModule
INFO ioc.RegistryBuilder] Adding module definition for class
org.apache.tapestry5.services.pageload.PageLoadModule
WARN TapestryFilter] Application Module class
com.rakesh.demotapestry.web.services.TapestryModule not found
INFO TapestryFilter] Startup status:
Any help greatly appreciated.
Thanks in advance,
Rakesh
-
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: Triggering a form submission via JavaScript in 5.4-alpha2
Still no progress on this.
I forgot to mention that this is with a zone.
@Lance: I rendered a submit button (not hidden, for now):
t:form ... zone=listZone
t:submit t:id=categorySubmit id=categorySubmit value=Go/
/t:form
and then
t:select onchange=console.log(onchange executing.);
document.getElementById('categorySubmit').fire('submit') /
The JavaScript console shows the 'onchange executing. output but
nothing else happens (and no errors).
@Steve
Tried this.form.fire(submit), with no change. Still nothing happens.
On Sat, Mar 9, 2013 at 12:42 PM, Steve Eynon
steve.ey...@alienfactory.co.uk wrote:
Try this:
this.form.fire(submit)
I've not tried it, but I was looking at:
http://people.apache.org/~hlship/t5api/coffeescript/forms.html
Steve.
---
If at first you don't succeed,
so much for skydiving!
-
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: Triggering a form submission via JavaScript in 5.4-alpha2
You need to fire the click event on the submit button, not submit. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Triggering-a-form-submission-via-JavaScript-in-5-4-alpha2-tp5720381p5720404.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: Triggering a form submission via JavaScript in 5.4-alpha2
In 5.3, you had to do setSubmittingElement(). Not sure if this applies still in 5.4, but if it does, it will need to be called. On Mar 10, 2013, at 1:39 PM, Lance Java wrote: You need to fire the click event on the submit button, not submit. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Triggering-a-form-submission-via-JavaScript-in-5-4-alpha2-tp5720381p5720404.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 - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: First stab at CDI module for tapestry
Also, you can secure CDI beans using Tapestry-security using this:
http://code.google.com/p/flowlogix/wiki/TLShiroSecurityInterceptor
On Mar 10, 2013, at 5:15 AM, Lenny Primak wrote:
Kalle, that is exactly correct.
The CDI stuff (and by extension the CDI code in FlowLogix) which is taken
direct from CDI module
is so meant to use CDI beans in Tapestry, not use Tapestry services as CDI
beans.
On Mar 10, 2013, at 1:58 AM, Kalle Korhonen wrote:
Both of these seem to be about referencing and using CDI managed beans in
Tapestry services, please correct me if I'm wrong. What I'm asking is the
reverse - using Tapestry services in applications frameworks expecting a
CDI environment.
Kalle
On Sat, Mar 9, 2013 at 3:41 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote:
Actually, the CDI SPI statement may not be accurate.
CDI support uses BeanManager to do its job, so its CDI SPI. Not sure,
Kalle, if that's what you are referring to.
http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/web/services/CDIModule.java
On Mar 9, 2013, at 5:56 PM, Lenny Primak wrote:
I would love to contribute the FlowLogix module, or as much of it as it
still applies to tapestry 5.4 into the core. It includes CDI support plus
the JEE stack support.
The CDI interface doesn't use SPI yet.
On Mar 9, 2013, at 5:34 PM, Kalle Korhonen kalle.o.korho...@gmail.com
wrote:
Hey Magnus,
as part of your tapestry-cdi work, did you look into implementing a
Tapestry CDI SPI, i.e. an implementation of
javax.enterprise.inject.spi.BeanManager? This is related to my earlier
thread about injectable entitylisteners (
http://mail-archives.apache.org/mod_mbox/tapestry-dev/201210.mbox/%3CCA+=ewnb+tjv01fiyzsded3u5iyop3wcf1r3prhqtdjrm7ix...@mail.gmail.com%3E
).
JPA 2.1 is required the check the SPI (see
http://java.dzone.com/articles/cdi-extensions-you-can-build,
http://java.net/downloads/jpa-spec/JavaPersistencePFD.pdf,
http://stackoverflow.com/questions/12951701/how-to-get-entity-manager-or-transaction-in-jpa-listener
,
http://stackoverflow.com/questions/11740322/cdi-injection-is-not-working-in-servlets
).
The CDI is a solid spec, we should start thinking about offering
tapestry-cdi or similar as a core Tapestry module.
Kalle
On Thu, Aug 18, 2011 at 11:59 AM, Magnus Kvalheim mag...@kvalheim.dk
wrote:
Yes, I've noticed. Great work Igor :)
I've intentionally not done anything for tapestry-cdi in terms of
supporting
javax.inject.@Inject.
As Tap @inject and javax @inject are interchangeable - cdi bean
injection
with either @inject should 'just work' with tapestry-cdi and T5.3 :)
On Thu, Aug 18, 2011 at 12:56 PM, Igor Drobiazko
igor.drobia...@gmail.comwrote:
Just as a side note: starting with T5.3 it's possible to use JSR 330
for
injection.
Check this out:
http://tapestry.apache.org/using-jsr-330-standard-annotations.html
On Wed, Jun 8, 2011 at 1:56 PM, Magnus Kvalheim mag...@kvalheim.dk
wrote:
Hi all,
We're looking into moving our apps from a 'traditional' servlet
container
with spring into a Java EE web profile server like glassfish 3.1.
Motivations for doing this is to utilize cdi(jsr 299, 330), ejb3 and
more.
Not just for the tapestry app, but also the other applications in
our portfoleo which share common core business logic.
For reference on previous discussions:
http://tapestry.1045711.n5.nabble.com/Java-based-spring-configuration-td3394086.html
http://tapestry.1045711.n5.nabble.com/Discussion-td2421783i20.html
Now, I've tried running the tapestry quickstart app in glassfish 3.1
(with
the eclipse connector for publishing).
This works ok - although I cannot make live class reloading work. :(
Glassfish uses Weld, so the CDIModule is basically an objectprovider
for
injecting Weld managed beans.
(As you probably know CDI/Weld can also be used outside jee as
alternative
to tapestry-ioc, spring, etc)
*CDIModule class*
*public class CDIModule { *
* public static void bind(ServiceBinder binder) {*
*binder.bind(ObjectProvider.class,
CDIObjectProvider.class).withId(CDIObjectProvider);*
*} *
* public static BeanManager buildBeanManager(Logger log) { *
* try {*
* BeanManager beanManager = (BeanManager) new
InitialContext().lookup(java:comp/BeanManager);*
* return beanManager; *
* } catch (NamingException e) {*
* log.error(Could not lookup jndi resource: java:comp/BeanManager,
e);*
* }*
* return null;*
* } *
* public static void contributeMasterObjectProvider(*
* @InjectService(CDIObjectProvider) ObjectProvider cdiProvider,*
* OrderedConfigurationObjectProvider configuration) { *
*// configuration.add(cdiProvider, cdiProvider,
after:Service,after:AnnotationBasedContributions,after:Alias,after:Autobuild);
*
* configuration.add(cdiProvider, cdiProvider, after:*); *
* } *
*}*
*
*
The beanmanager is expected to be found in jndi. If the
Re: Triggering a form submission via JavaScript in 5.4-alpha2
Oh, I see - you have inline javascript in the onchange handler. I
don't think that's going to work - you need to wrap the element in T5s
core DOM which is defined by RequireJS:
http://people.apache.org/~hlship/t5api/coffeescript/t5-core-dom-prototype.html
Do this instead:
/META-INF/modules/formSubmitter.js
define([t5/core/dom], function(t5) {
return function(selectClientId) {
return t5(selectClientId).on('change', function(e) {
var form = this.findParent(form);
return form.trigger(submit);
});
};
});
Or use CoffeeScript:
/META-INF/modules/formSubmitter.coffee
define [t5/core/dom], (t5) -
return (selectClientId) -
t5(selectClientId).on 'change', (e) -
form = this.findParent(form)
form.trigger submit
Then in a render phase method in your component / page:
jsSupport.require(formSubmitter).with(select.getClientId());
Steve.
On 11 March 2013 02:32, Lenny Primak lpri...@hope.nyc.ny.us wrote:
In 5.3, you had to do setSubmittingElement(). Not sure if this applies still
in 5.4, but if it does,
it will need to be called.
On Mar 10, 2013, at 1:39 PM, Lance Java wrote:
You need to fire the click event on the submit button, not submit.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Triggering a form submission via JavaScript in 5.4-alpha2
Steve,
Yeah, I hadn't gotten around to switching this code to unobtrusive
JavaScript yet and was hoping for a quick substitute.
Your code did the trick, it works perfectly.
Of course, I'll still need to adjust the module to set up a additional
event handlers for other events, but I guess I can figure that out
(i.e. Initialize#invoke(String)) now that you've given me a good
start.
Thanks!
On Sun, Mar 10, 2013 at 8:28 PM, Steve Eynon
steve.ey...@alienfactory.co.uk wrote:
Oh, I see - you have inline javascript in the onchange handler. I
don't think that's going to work - you need to wrap the element in T5s
core DOM which is defined by RequireJS:
http://people.apache.org/~hlship/t5api/coffeescript/t5-core-dom-prototype.html
Do this instead:
/META-INF/modules/formSubmitter.js
define([t5/core/dom], function(t5) {
return function(selectClientId) {
return t5(selectClientId).on('change', function(e) {
var form = this.findParent(form);
return form.trigger(submit);
});
};
});
Or use CoffeeScript:
/META-INF/modules/formSubmitter.coffee
define [t5/core/dom], (t5) -
return (selectClientId) -
t5(selectClientId).on 'change', (e) -
form = this.findParent(form)
form.trigger submit
Then in a render phase method in your component / page:
jsSupport.require(formSubmitter).with(select.getClientId());
Steve.
On 11 March 2013 02:32, Lenny Primak lpri...@hope.nyc.ny.us wrote:
In 5.3, you had to do setSubmittingElement(). Not sure if this applies
still in 5.4, but if it does,
it will need to be called.
On Mar 10, 2013, at 1:39 PM, Lance Java wrote:
You need to fire the click event on the submit button, not submit.
-
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: First stab at CDI module for tapestry
We are using FlowLogix CDI support in production now. The code is basically taken from Magnus' module, and enhanced it a bit to be more resilient in case CDI is not present. We've been using it in production for 6 months and it works great. On Mar 10, 2013, at 5:56 PM, Magnus Kvalheim wrote: Hi. Our motivation at the time was to investigate a move from a spring stack to a jee one. Most is written using jee annotations, with spring behind the scenes, so a switch looked feasible. I made the tapestry-cdi module which bridged the gap on tapestry side. ( https://github.com/magnuskvalheim/tapestry-cdi ). It worked quite well and got our apps playing nice with jee; jboss as7, jpa, cdi, +more and tapestry. But in the end it didn't move past sandbox stage and we're still with spring. It was a nice experience though and I found CDI quite solid and powerful and think that Tapestry does deserve a first class CDI module. We never had any need to to do the reverse (expose tapestry services to cdi) so we didn't explore that in detail. Tapestry IOC has a lot going for it as well so I can see that some would like the option to go that direction as well. I think that maybe CDI-Tapestry and Tapestry-CDI should be two separate modules. Or if it's in same module - have a convenient way to configure what directions for it to operate. For CDI-Tapestry I would be happy to donate my module if it can be useful. Think maybe Lenny have some production related experience with it. The other mentioned, cdi-tapestry-contribution ( https://github.com/rmannibucau/cdi-tapestry-contribution ) looks good and could be used somewhere in production as well. IMO we only need one good supported one :-) --magnus On Sun, Mar 10, 2013 at 10:15 AM, Lenny Primak lpri...@hope.nyc.ny.uswrote: Kalle, that is exactly correct. The CDI stuff (and by extension the CDI code in FlowLogix) which is taken direct from CDI module is so meant to use CDI beans in Tapestry, not use Tapestry services as CDI beans. On Mar 10, 2013, at 1:58 AM, Kalle Korhonen wrote: Both of these seem to be about referencing and using CDI managed beans in Tapestry services, please correct me if I'm wrong. What I'm asking is the reverse - using Tapestry services in applications frameworks expecting a CDI environment. Kalle On Sat, Mar 9, 2013 at 3:41 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote: Actually, the CDI SPI statement may not be accurate. CDI support uses BeanManager to do its job, so its CDI SPI. Not sure, Kalle, if that's what you are referring to. http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/web/services/CDIModule.java On Mar 9, 2013, at 5:56 PM, Lenny Primak wrote: I would love to contribute the FlowLogix module, or as much of it as it still applies to tapestry 5.4 into the core. It includes CDI support plus the JEE stack support. The CDI interface doesn't use SPI yet. On Mar 9, 2013, at 5:34 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: Hey Magnus, as part of your tapestry-cdi work, did you look into implementing a Tapestry CDI SPI, i.e. an implementation of javax.enterprise.inject.spi.BeanManager? This is related to my earlier thread about injectable entitylisteners ( http://mail-archives.apache.org/mod_mbox/tapestry-dev/201210.mbox/%3CCA+=ewnb+tjv01fiyzsded3u5iyop3wcf1r3prhqtdjrm7ix...@mail.gmail.com%3E ). JPA 2.1 is required the check the SPI (see http://java.dzone.com/articles/cdi-extensions-you-can-build, http://java.net/downloads/jpa-spec/JavaPersistencePFD.pdf, http://stackoverflow.com/questions/12951701/how-to-get-entity-manager-or-transaction-in-jpa-listener , http://stackoverflow.com/questions/11740322/cdi-injection-is-not-working-in-servlets ). The CDI is a solid spec, we should start thinking about offering tapestry-cdi or similar as a core Tapestry module. Kalle On Thu, Aug 18, 2011 at 11:59 AM, Magnus Kvalheim mag...@kvalheim.dk wrote: Yes, I've noticed. Great work Igor :) I've intentionally not done anything for tapestry-cdi in terms of supporting javax.inject.@Inject. As Tap @inject and javax @inject are interchangeable - cdi bean injection with either @inject should 'just work' with tapestry-cdi and T5.3 :) On Thu, Aug 18, 2011 at 12:56 PM, Igor Drobiazko igor.drobia...@gmail.comwrote: Just as a side note: starting with T5.3 it's possible to use JSR 330 for injection. Check this out: http://tapestry.apache.org/using-jsr-330-standard-annotations.html On Wed, Jun 8, 2011 at 1:56 PM, Magnus Kvalheim mag...@kvalheim.dk wrote: Hi all, We're looking into moving our apps from a 'traditional' servlet container with spring into a Java EE web profile server like glassfish 3.1. Motivations for doing this is to utilize cdi(jsr 299, 330), ejb3 and more. Not just for the tapestry app, but also the other applications in our
Re: Triggering a form submission via JavaScript in 5.4-alpha2
Yeah, sometimes quick fixes, well, aren't!
But cool. As you're using Zones I'll mention another trick...
If you put the event handler on the document, or some parent element
that doesn't get updated, then you don't have to re-apply the event
handler on every zone / ajax update.
e.g. the following will submit the form on all select change events
and you only ever need to call jsSupport.require() once when the page
loads:
define [t5/core/dom], (t5) -
return -
t5.onDocument change, select, (e) -
form = this.findParent(form)
form.trigger submit
Steve.
On 11 March 2013 09:06, Bob Harner bobhar...@gmail.com wrote:
Steve,
Yeah, I hadn't gotten around to switching this code to unobtrusive
JavaScript yet and was hoping for a quick substitute.
Your code did the trick, it works perfectly.
Of course, I'll still need to adjust the module to set up a additional
event handlers for other events, but I guess I can figure that out
(i.e. Initialize#invoke(String)) now that you've given me a good
start.
Thanks!
On Sun, Mar 10, 2013 at 8:28 PM, Steve Eynon
steve.ey...@alienfactory.co.uk wrote:
Oh, I see - you have inline javascript in the onchange handler. I
don't think that's going to work - you need to wrap the element in T5s
core DOM which is defined by RequireJS:
http://people.apache.org/~hlship/t5api/coffeescript/t5-core-dom-prototype.html
Do this instead:
/META-INF/modules/formSubmitter.js
define([t5/core/dom], function(t5) {
return function(selectClientId) {
return t5(selectClientId).on('change', function(e) {
var form = this.findParent(form);
return form.trigger(submit);
});
};
});
Or use CoffeeScript:
/META-INF/modules/formSubmitter.coffee
define [t5/core/dom], (t5) -
return (selectClientId) -
t5(selectClientId).on 'change', (e) -
form = this.findParent(form)
form.trigger submit
Then in a render phase method in your component / page:
jsSupport.require(formSubmitter).with(select.getClientId());
Steve.
On 11 March 2013 02:32, Lenny Primak lpri...@hope.nyc.ny.us wrote:
In 5.3, you had to do setSubmittingElement(). Not sure if this applies
still in 5.4, but if it does,
it will need to be called.
On Mar 10, 2013, at 1:39 PM, Lance Java wrote:
You need to fire the click event on the submit button, not submit.
-
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: Triggering a form submission via JavaScript in 5.4-alpha2
Cool, thanks!
I'm starting to build up some content for 5.4 documentation updates,
and all this goes in there.
On Sun, Mar 10, 2013 at 9:36 PM, Steve Eynon
steve.ey...@alienfactory.co.uk wrote:
Yeah, sometimes quick fixes, well, aren't!
But cool. As you're using Zones I'll mention another trick...
If you put the event handler on the document, or some parent element
that doesn't get updated, then you don't have to re-apply the event
handler on every zone / ajax update.
e.g. the following will submit the form on all select change events
and you only ever need to call jsSupport.require() once when the page
loads:
define [t5/core/dom], (t5) -
return -
t5.onDocument change, select, (e) -
form = this.findParent(form)
form.trigger submit
Steve.
On 11 March 2013 09:06, Bob Harner bobhar...@gmail.com wrote:
Steve,
Yeah, I hadn't gotten around to switching this code to unobtrusive
JavaScript yet and was hoping for a quick substitute.
Your code did the trick, it works perfectly.
Of course, I'll still need to adjust the module to set up a additional
event handlers for other events, but I guess I can figure that out
(i.e. Initialize#invoke(String)) now that you've given me a good
start.
Thanks!
On Sun, Mar 10, 2013 at 8:28 PM, Steve Eynon
steve.ey...@alienfactory.co.uk wrote:
Oh, I see - you have inline javascript in the onchange handler. I
don't think that's going to work - you need to wrap the element in T5s
core DOM which is defined by RequireJS:
http://people.apache.org/~hlship/t5api/coffeescript/t5-core-dom-prototype.html
Do this instead:
/META-INF/modules/formSubmitter.js
define([t5/core/dom], function(t5) {
return function(selectClientId) {
return t5(selectClientId).on('change', function(e) {
var form = this.findParent(form);
return form.trigger(submit);
});
};
});
Or use CoffeeScript:
/META-INF/modules/formSubmitter.coffee
define [t5/core/dom], (t5) -
return (selectClientId) -
t5(selectClientId).on 'change', (e) -
form = this.findParent(form)
form.trigger submit
Then in a render phase method in your component / page:
jsSupport.require(formSubmitter).with(select.getClientId());
Steve.
On 11 March 2013 02:32, Lenny Primak lpri...@hope.nyc.ny.us wrote:
In 5.3, you had to do setSubmittingElement(). Not sure if this applies
still in 5.4, but if it does,
it will need to be called.
On Mar 10, 2013, at 1:39 PM, Lance Java wrote:
You need to fire the click event on the submit button, not submit.
-
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
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
