Re: [VOTE] Tapestry Release 5.3.8
Kristian Marinkovic: +1 (non-binding) On Fri, Nov 21, 2014 at 4:48 AM, Howard Lewis Ship wrote: > Howard M. Lewis Ship: +1 (binding) > > 2014-11-20 16:50 GMT-05:00 françois facon : > > > François Facon: : +1 (non-binding) > > > > > > -- > 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 > @hlship >
Re: [VOTE] Drop support for Java 5 in Tapestry 5.4 (2nd attempt)
Kristian Mairnkovic: +1 (non-binding) i don't see any reason not to raise the minimun requirement to 1.6. i've to admit most of my Tapestry apps run on Java 1.6. anyways. On Mon, May 19, 2014 at 1:54 PM, Bob Harner wrote: > Bob Harner: +1 (non-binding) > On May 18, 2014 1:05 PM, "Jochen Kemnade" wrote: > > > There have been discussions whether we want to keep compatibility with > > Java 5 for the upcoming 5.4 release. > > Java 5 is EOSL since October 2009. > > While requiring Java 6 would not bring us much benefits, there might be > > some libraries that we cannot use because they do not support Java 5. > > Also, we'd spare ourselves some efforts not having to support Java 5 > > anymore. > > The vote will run for 3 days and, if it succeeds, I will increase the > > minimum required Java version to 1.6. > > > > Jochen Kemnade: +1 (non-binding) > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: dev-h...@tapestry.apache.org > > > > > > >
Re: [VOTE] Tapestry 5.4-beta-6
Kristian Marinkovic: +1 (non-binding) On Sat, May 17, 2014 at 10:48 AM, françois facon wrote: > François Facon: +1 (non-binding) > > > 2014-05-15 23:39 GMT+02:00 Howard Lewis Ship : > > > I've created and uploaded a release of Tapestry 5.4-beta-6, ready to be > > voted upon. > > > > The source and source downloads are uploaded to: > > > > http://people.apache.org/~hlship/tapestry-releases/ > > > > and the Maven artifacts staged to: > > > > > https://repository.apache.org/content/repositories/orgapachetapestry-1014 > > > > Please examine these files to determine if the new release, 5.4-beta-6, > is > > ready. > > > > I've also created a 5.4-beta-6 tag in Git: > > > > > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=c5600a8de7645fb7bd5cc21b38f8902a36c1b840 > > > > Vote will run for three days; On a successful vote, I'll release the > Maven > > artifacts, and move the source and javadoc distributions from these > > directories > > to the proper distribution directories and update the Tapestry site > > documentation, and send out appropriate notifications. > > > > > > Howard M. Lewis Ship: +1 (binding) > > > > -- > > 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 > > @hlship > > >
Re: [VOTE] Apache Tapestry 5.4-beta-3 release
Kristian Marinkovic: +1 (non-binding) everything works as expected On Thu, Feb 20, 2014 at 5:43 PM, Kalle Korhonen wrote: > Kalle Korhonen: +1 (non-binding) > > > On Thu, Feb 20, 2014 at 8:19 AM, françois facon > wrote: > > > François Facon: +1 (non-binding) > > > > > > 2014-02-20 9:52 GMT+01:00 Massimo Lusetti : > > > > > Massimo Lusetti: +1 (binding) > > > > > > > > > On Wed, Feb 19, 2014 at 11:36 PM, Howard Lewis Ship > > >wrote: > > > > > > > I've created and uploaded a release of Tapestry 5.4-beta-3, ready to > be > > > > voted upon. > > > > > > > > The source and source downloads are uploaded to: > > > > > > > > http://people.apache.org/~hlship/tapestry-releases/ > > > > > > > > and the Maven artifacts staged to: > > > > > > > > https://repository.apache.org/content/groups/staging/ > > > > > > > > Please examine these files to determine if the new beta release, > > > > 5.4-beta-3, is ready. > > > > > > > > I've also created a 5.4-beta-3 tag in Git: > > > > > > > > > > > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=c2d46ef28dff5186da1e52bd88168ad04cd30f56 > > > > > > > > Vote will run for three days; On a successful vote, I'll release the > > > Maven > > > > artifacts, and move the source and javadoc distributions from these > > > > directories > > > > to the proper distribution directories and update the Tapestry site > > > > documentation, and send out appropriate notifications. > > > > > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > > > > -- > > > Massimo Lusetti > > > > > >
Re: [VOTE] Lance Semmens as a committer
+1 (Non binding) Am 03.07.2013 21:44 schrieb "Kalle Korhonen" : > Lance Semmens (aka Lance Java) has been one of the most active members on > the user list for the past two years. I've personally committed a few > patches from him and he is the maintainer of tapestry-stitch ( > https://github.com/uklance/tapestry-stitch/), a collection of sample > components and concepts for Tapestry 5. Howard has spoke with him privately > and he's interested in joining as a committer. Vote to run for a minimum of > three days. > > Kalle Korhonen: +1 (non-binding) >
Re: jQuery 2.x or stick with 1.x?
+1 Am 26.05.2013 19:01 schrieb "Jochen Frey" : > +1 > > -- j > > On May 26, 2013, at 9:06 AM, Emmanuel DEMEY > wrote: > > > +1 !!! > > > > > > 2013/5/26 Dimitris Zenios > > > >> +1 > >> > >> > >> On Sun, May 26, 2013 at 6:58 PM, Howard Lewis Ship > >> wrote: > >> > >>> What do people think about moving the embedded jQuery library up to the > >> 2.x > >>> version? I would tend to favor the idea, given that anyone who truly > >> cares > >>> can switch it back. > >>> > >>> -- > >>> 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 > > > > > > > > -- > > Emmanuel DEMEY > > Ingénieur Etude et Développement > > ATOS Worldline > > +33 (0)6 47 47 42 02 > > demey.emman...@gmail.com > > http://emmanueldemey.fr/ > > > > Twitter : @EmmanuelDemey > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: TAP5-2049 - Exclusive session access
+1 that is a good idea Am 16.01.2013 15:46 schrieb "Ulrich Stärk" : > > > On 16.01.2013 00:04, Josh Canfield wrote: > > > > > @Persist(concurrent=false) > > > > In Spring they solved this by allowing you to tell each controller whether > to synchronize requests > using the session object or not. In Tapestry this could be as easy as a > @Synchronized annotation on > methods that should be synchronized and a TransformWorker that would wrap > such methods inside a > synchronized block. > > Uli > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: Page pooling in Tapestry 5.0
@Persist fields are NOT shared between sessions. Otherwise all my deployed applications wouldn't work. you do realize that you are initializing your fields in the onActivate method? And because they are properties you could have bound it to a form field. have you checked that you got a new http session? just a logout link won't do unless it invalidates the current http session; check your cookies. @Persist works as expected, no doubt. On Thu, Nov 8, 2012 at 8:25 AM, Javicha wrote: > I was wrong, Tapestry version is 5.1.0.5 (not 5.0). > > And I have found that @Persist if shared between sessions (I do a search by > name 'Peter'. I log out. I log on with a different user session. I go to the > search page, and it´s initialized with the parameter 'Peter'). It's a very > strange problem. I think I'll delete the @Persist annotation, and pass all > the search parameters in methods OnActivate - onPassivate to resolve > problem. > > Thanks to all for the help! > > > > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/Page-pooling-in-Tapestry-5-0-tp5717748p5717807.html > Sent from the Tapestry - Dev mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Tapestry 5.3.6
Kristian Marinkovic: +1 (non-binding) works for me; even updated tapestry-jquery to 3.3.2 wihtout problems On Tue, Oct 9, 2012 at 7:37 PM, Lenny Primak wrote: > Lenny Primak: +1 (non-binding) > > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: A plan for 5.3 / 5.4
i guess your roadmaps (igor, howard) are very promising.
what i am missing is a decent (official) portlet support in T5. This was
the main reason some of my customers refused to switch to T5 and chose JSF
instead (with Liferay). They were all quite impressed by T5 features but
they didn't want to spend their effort in maintaining a custom portlet
solution. Those costumers are big companies that already have some kind of
portlet support and want to reuse their infrastructure. Almost everytime
we were presenting T5 and its advantages to some managers, someone had to
ask: does it support portlets (event if they don't use it!). from my
experience this is a big selling point.
a new JS infrastructure / abstraction layer is overdue as this is the
reason why there are no (at least not many) fancy JS enabled controls and
widgets for T5. because everytime you think of creating one, you remember
that T5 depends on prototype and you dont want to use it anymore. but
writing T5 components that depend on JQuery, dojo, ... doesn't feel right
too. i think it would be a big advantage if you could write js library
agnostic components (with some additional adapters if necessary) and adapt
to your customers needs.
i'm still not convinced moving from gradle to maven is a good idea. for me
maven works great and almost any it-company nowadays is familiar with it.
we are building a custom OSGIfied version of T5.2 using maven. i don't
know how to achieve the same result with gradle. Also from my point of
view having a default project layout for all java projects (especially
open source) is a good (not to say great) idea!
g,
kris
Von:Howard Lewis Ship
An: Tapestry development
Datum: 08.02.2011 22:34
Betreff:Re: A plan for 5.3 / 5.4
Javassist vs. Plastic vs. ComponentClassTransformWorker
Imagine if you could contribute a "classic"
ComponentClassTransformWorker or some new interface for working with a
Plastic class, both to the same service:
ComponentClassTransformWorker. The "classic" style would be
transformed, via TypeCoercer, to the new form. And, of course, we'd
make that work for all service configurations. That's my plan,
anyway. Configurations should, instead of complaining that provided
types are bad, attempt to coerce first.
I think the new interface will look more like:
public interface ComponentClassTransformer
{
void transformClass(PlasticClass componentClass, MutableComponentModel
model);
}
On Tue, Feb 8, 2011 at 1:25 PM, Igor Drobiazko
wrote:
> Having an official road map would be a great improvement for Tapestry.
Also
> having two releases in 2011 is great.
>
> My plans for 5.3/5.4 are:
>
> - Support for JSR-330 (almost done)
> - Support for some HTML5 features
> - Support for "multidimensional" caching of pages, components, etc.
> - Helping you out by migrating from javassist to plastic (I already
started
> learning ASM + Plastic)
> - Maybe some support for other frameworks: Event though we having JPA
> support in Tynomo, I'm thinking to move it into Tapestry? Such a widely
used
> framework should be supported.
>
> Along the way I'm working on the book which hopefully will be released
> before summer.
>
> What do you think about moving some stuff from tapx to Tapestry core?
>
> On Tue, Feb 8, 2011 at 7:13 PM, Howard Lewis Ship
wrote:
>
>> Been chatting with clients (who may help fund this) and just thinking
>> about plans. Here's a rough outline of what I think I can commit to
>> in 5.3 and 5.4.
>>
>> 5.3
>> - Deprecate Javassist inside ComponentClassInstantiator, replace with
>> Plastic
>> - Deprecate ClassFactory, provide necessary hooks to use Plastic
>> - Move Plastic into Tapestry?
>> - Gradle build for Tapestry
>> - Improve debugging experience (shadow per-thread values into shared
>> object fields in development mode)
>> - Improve asset pipelines for
>> - Dynamic generation of content (example, .less files converted to
>> static CSS automatically)
>> - JS/CSS minimization
>> - Do something about Component Report ... turn it into an Ant task,
>> perhaps, or integrate Component Report into JavaDoc directly
>> - Minor JS improvements, set expectations for 5.4 rewrite
>>
>> 5.4
>> - Remove Javassist entirely
>> - Remove ClassFactory
>> - Rewrite JS entirely, introduce abstraction layer and backwards
>> compatibility layer
>> - Maybe cometd/server-push support
>>
>> I'd love to see both these releases in 2011.
>>
>> In case you missed in: http://github.com/hlship/plastic
>>
>> --
>> 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: dev-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: dev-h...@tapestry.apache.org
>>
>>
>
>
> --
> Best
Re: [VOTE] remove bwallace from committers list
Kristian Marinkovic: +1 (non-binding) Von:Howard Lewis Ship An: Tapestry development Datum: 23.01.2011 01:45 Betreff:Re: [VOTE] remove bwallace from committers list Howard M. Lewis Ship: +1 (binding) On Sat, Jan 22, 2011 at 4:42 PM, Andreas Andreou wrote: > Andreas Andreou: +1 (binding) > > On Sun, Jan 23, 2011 at 02:05, Charith Madusanka > wrote: > > Charitha Madusanka: +1 (non-binding) > > > > On Sat, Jan 22, 2011 at 11:59 PM, Ulrich Stärk wrote: > > > >> bwallace has been last seen May 24, 2006. I guess it's safe to assume he > >> doesn't want to be involved with Tapestry anymore. Any objections > against > >> revoking his commit privileges and cleaning up the committers lists? > >> > >> Vote to run for 72 hours. > >> > >> Ulrich Stärk: +1 (binding) > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: dev-h...@tapestry.apache.org > >> > >> > > > > > > -- > Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr > Tapestry PMC / Tacos developer > Open Source / JEE Consulting > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- 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
Antwort: Re: [VOTE] Kalle Korhonen as Tapestry Committer
Kristian Marinkovic: +1 (non-binding) Von:Christophe Cordenier An: Tapestry development Datum: 11.01.2011 09:43 Betreff:Re: [VOTE] Kalle Korhonen as Tapestry Committer Christophe Cordenier: +1 (non-binding) 2011/1/11 Massimo Lusetti > On Mon, Jan 10, 2011 at 10:25 PM, Howard Lewis Ship > wrote: > > > This one seems a bit overdue ... Kalle has been active on the mailing > lists > > for quite some time, and has been actively evangelizing Tapestry and > > building toolkits on top of it for a while. I fell that having Kalle as > a > > committer will accelerate the development of both Tapestry and Tynamo, > among > > other benefits. > > Great! > > Massimo Lusetti: +1 (non-binding) > > Cheers > -- > Massimo > http://meridio.blogspot.com > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Regards, Christophe Cordenier. Committer on Apache Tapestry 5 Co-creator of wooki @wookicentral.com
Re: [VOTE] Tapestry 5.2.4
took me some time to test my apps kristian marinkovic: +1 (non-binding) Von:Ulrich Stärk An: Tapestry development Datum: 17.11.2010 20:56 Betreff:Re: [VOTE] Tapestry 5.2.4 Ulrich Stärk: +1 (binding) Am 15.11.2010 um 19:29 schrieb Howard Lewis Ship : > I've created and uploaded a release of Tapestry 5.2.4, ready to be > voted upon. This corrects the problem with the quickstart archetype (I've > downloaded > the new version and double-checked that the version number is 5.2.4). > > The binary and source downloads are uploaded to: > > http://people.apache.org/~hlship/tapestry-releases/ > > and the Maven artifacts staged to: > > https://repository.apache.org/content/repositories/orgapachetapestry-006/org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.2.4, is ready. > > I've also created a 5.2.4 tag in Subversion: > > http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.2.4/ > > On a successful vote, I'll move the files from these directories to > the proper distribution directories and update the Tapestry site > documentation. > > Vote will run for three days; on success I'll move the voted artifacts > into place and send out appropriate notifications. > > -- > 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: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Tapestry 5.2.1 beta release
Kristian Marinkovic: +1 (non-binding) Von:Ben Dotte An: Tapestry development Datum: 30.09.2010 17:12 Betreff:Re: [VOTE] Tapestry 5.2.1 beta release Ben Dotte: +1 (non-binding) On Thu, Sep 30, 2010 at 7:17 AM, Thiago H. de Paula Figueiredo wrote: > Thiago H. de Paula Figueiredo: +0 (binding). I couldn't play with Tapestry > 5.2 nor 5.2.1 yet, unfortunately. :( > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and > instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Josh Canfield as Committer
kristian marinkovic: +1 (non-binding) Von:Massimo Lusetti An: Tapestry development Datum: 04.09.2010 18:10 Betreff:Re: [VOTE] Josh Canfield as Committer On Thu, Sep 2, 2010 at 11:34 PM, Howard Lewis Ship wrote: > Josh Canfield has been very active in the Tapestry community for quite > some time; he was an early evangalist for Tapestry 5 and has deployed > multiple Tapestry 5 applications. He's also been very active in the > mailing list, and has provided some terrific patches, including one > that largely addresses the mismatch between generics and Tapestry's > property expression language. I've spoken with him, and he is eager to > join the team. > > Howard M. Lewis Ship: +1 (binding) > > Massimo Lusetti: +1 (non-binding) -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Committer status for Robin Komiwes
Kristian Marinkovic: +1 (non-binding) Von:Massimo Lusetti An: Tapestry development Datum: 15.07.2010 09:21 Betreff:Re: [VOTE] Committer status for Robin Komiwes On Wed, Jul 14, 2010 at 9:23 PM, Ulrich Stärk wrote: > Robin has continued to provide valuable contributions to Tapestry in the > form of a new logo, a slogan and two new website designs, one of which is > currently being integrated into our new website, as well as through > mentoring on the users mailing list. I'd therefore like to make Robin a > committer. Please cast your votes within the next 72 hours. Please also use > the scheme ": (binding/non-binding)" when voting. That will > facilitate compiling the results. Massimo Lusetti: +1 (non-binding) Cheers -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Ulrich Stärk to Tapestry PMC
Kristian Marinkovic: +1 (non-binding) Von:Charith Madusanka An: Tapestry development Datum: 22.06.2010 04:21 Betreff:Re: [VOTE] Ulrich Stärk to Tapestry PMC Charith Madusanka : +1 (non-binding) On Tue, Jun 22, 2010 at 4:55 AM, Andreas Andreou wrote: > Andreas Andreou: +1 (binding) > > On Tue, Jun 22, 2010 at 02:04, Josh Canfield > wrote: > > Josh Canfield: +1 (non-binding) > > > > -- Josh > > > > On Jun 21, 2010, at 1:16 PM, Howard Lewis Ship wrote: > > > >> In case anyone's missed, Ulrich has been doing a stellar job of > >> organizing many different efforts within Tapestry of late; including > >> work on the new documentation system and the new logo. He's been doing > >> the work of a PMC member without the recognition, so let's address > >> that. Let's add Ulrich to the PMC. > >> > >> Howard M. Lewis Ship: +1 (binding) > >> > >> > >> -- > >> 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: dev-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: dev-h...@tapestry.apache.org > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: dev-h...@tapestry.apache.org > > > > > > > > -- > Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr > Tapestry PMC / Tacos developer > Open Source / JEE Consulting > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: [VOTE] Christophe Cordenier as Tapestry Committer
+1 (non-binding) g, kris Von:Igor Drobiazko An: Tapestry development Datum: 15.06.2010 07:09 Betreff:Re: [VOTE] Christophe Cordenier as Tapestry Committer Igor Drobiazko: +1 (binding) On Mon, Jun 14, 2010 at 9:37 PM, Howard Lewis Ship wrote: > Along with Robin, Christophe Cordenier has been doing some fantastic > work on Wooki and its related set of libraries. Further, he's been > very visible on the mailing list doing a lot of mentoring. I think > Christophe is the kind of person we need as a Tapestry committer, not > just working on the fringes. A +1 vote will add Christophe to the > Tapestry committer team. > > Howard M. Lewis Ship: +1 (binding) > > -- > 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: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Best regards, Igor Drobiazko http://tapestry5.de/blog
Antwort: [VOTE] remove inactive members from the PMC
+1 (non-binding) g, kris Von:Andreas Andreou An: Tapestry development Datum: 09.06.2010 01:55 Betreff:[VOTE] remove inactive members from the PMC The vote is to remove the following inactive members David Solis Kent Tong Geoffrey Longman Mind Bridge Paul Ferraro Tsvetelin Saykov from the PMC. They have been inactive for at least a year now. Vote to run for four days. Andreas Andreou: +1 (binding) -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Tapestry PMC / Tacos developer Open Source / JEE Consulting - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] remove inactive PMC members from the PMC
+1 (non-binding) usually i'd agree with peter, but non of the mentioned members has been active for years. some even moved to other frameworks. it should be mentioned that some of the members made tremendous efforts to boost Tapestry 4.x. their removal should however not lessen their work but reflect their change in interest and focus . g, kris Von:Robert Zeigler An: "Tapestry development" Datum: 31.05.2010 20:40 Betreff:Re: [VOTE] remove inactive PMC members from the PMC Gesendet von: robert zeigler -1 (non-binding). It may be messier/take longer, but I would prefer to vote on a case-by-case basis rather than lumping all of the "inactive" PMC members together. Robert On May 31, 2010, at 5/318:22 AM , Ulrich Stärk wrote: > The vote is to clean up the list of PMC members and remove the members > > David Solis > Kent Tong > Geoffrey Longman > Mind Bridge > Paul Ferraro > Richard Lewis-Shell > Tsvetelin Saykov > > from the PMC. They have been inactive for at least a year now. If they wish to remain on the PMC they should vote -1. Their negative vote means that they will be excluded from the removal. Vote to run for seven days. > > Ulrich Stärk: +1 (non-binding) > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Tapestry bylaws
+1 (non-binding) Von:Ulrich Stärk An: Tapestry development Datum: 28.05.2010 10:16 Betreff:Re: [VOTE] Tapestry bylaws That's nothing to do with bureaucracy. It's meant to be a summary of how we do things here anyways, to make our processes more transparent to others and thus encouraging them to participate. Without that recorded knowledge it might take outsiders months to fully understand how we work and in that time distracting them from contributing. Additionally I hoped to clarify some things for ourselves as well since there seemed to be some misunderstandings among us e.g. concerning binding and non-binding votes and who is allowed to cast them and what they mean. Uli On 28.05.2010 04:08, Jesse Kuhnert wrote: > Yeah geez, you guys sound like a bunch of beurocrats right now. Who > cares? How is the project doing? > > On Thursday, May 27, 2010, Kalle Korhonen wrote: >> I did take a look at it earlier. Before I was thinking that it doesn't >> really change anything because technically any change triggers a lazy >> consensus vote, but still, it seems a little voting happy. What >> happens if somebody votes -1 +71 hours after commit? The commit needs >> to be automatically reverted back? The issue with automated triggering >> of lazy consensus votes is that there's nobody to gather the results. >> Of course, most of the time it doesn't matter but then again, what's >> the point of spelling it out explicitly? The existing Apache rules are >> minimal but good enough and worked for multiple projects for years. >> Overall, I'd say I prefer not voting for everything but "just get it >> done" attitude and explicit voting when needed. However, if community >> finds these rules are needed that's ok with me, thus still +0 >> (non-binding). >> >> Kalle >> >> >> On Thu, May 27, 2010 at 4:01 PM, Thiago H. de Paula Figueiredo >> wrote: >>> Take a look at the "When to vote with what voting style" section. I agree >>> that most of it is just how Apache project work, but there are some parts >>> that are specific for Tapestry. >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and >>> instructor >>> Owner, Ars Machina Tecnologia da Informação Ltda. >>> http://www.arsmachina.com.br >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: dev-h...@tapestry.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [DISCUSS] Tapestry homepage redesign
hi robin, i love the new design! in response to ulrichs suggestion, we could make the first row of links look like tabs... as seen on www.hibernate.org. it might be more visible then. g, kris Von:Robin Komiwes An: Tapestry development Datum: 25.05.2010 12:06 Betreff:[DISCUSS] Tapestry homepage redesign Gesendet von: odiss...@gmail.com I said some weeks ago that I will assist the documentation renew effort by proposing a redesign for Tapestry homepage. I'm quite satisfied with the first draft and I now need the community feedback to know if I should stop or continue this way. Of course, if someone wants to help on the content or the design, you are very welcome. The URLs : http://komiwes.fr/tapestry http://komiwes.fr/tapestry/getting_started.htm http://komiwes.fr/tapestry/community.htm Now, here are the key principles of this redesign. I've tried to follow them, and some may need to be expressed more. - Everything is marketing Others frameworks understand that well. They all have a shiny homepage, with key words, quotes from great people and baselines that you can't miss. The homepage should seduce and convince people. You've got to know that the framework you are using, or about to, is one of the best frameworks. In fact, there are plenty of good frameworks, if you launch tomorrow another "good framework", you are already dead. You need to offer a rockstar framework. On this redesign, a newcomer will be satisfied by how the information is clear and concise. He will know the concept of Tapestry (cf baseline) and will instantly have an idea of Tapestry strengths (cf Java power, scripting ease, highly productive). Finally he will be invited to give 20 minutes of its time to try the framework and realize how true was what we announced before. - Community Every framework should focus on its community. IMHO, that's another key point: again, if you think that an open source framework will buzz just because it is well made, you may have miss how the internet has evolved since some years. Ruby on Rails and jQuery have integrated that since the beginning. Focusing on the community is mandatory. Why? First, because as a Web framework developer, you can't cover every feature. Web is just too big. Especially in the Java ecosystem. If someone cover a feature for you, thanks him and then do advertising for its contribution as it was one of the features of the framework. It should be presented as a part of the framework itself, not as "a nice side project that you may look to if you want to...". Secondly, because the web is social. If people feels that they are part of an active community, they will be proud of it and will wants to make other people joining it. They will blog for you, they will evangelize for you. In fact, they will to the marketing job for you. I think the effort on this point should be pushed a lot further. We should have some specs on how to write and provide components library, how to provides plugins. We should have a place where to publish them. We should also have an open sourced keynote available to make presentations of Tapestry 5, like Howard's one : http://www.slideshare.net/hlship/tapestry-5-java-power-scripting-ease Everyone should be able to grab it and then do a presentation to its local JUG. - Fresh content It's important to look like active. We all know here that Tapestry is active but if you look at the actual website, there is no clue about that. Here, I think using a specific Twitter account (I've reserved @tapestry_5) for pushing news both on a social network and on the Tapestry website would be great. We would be able to easily push fresh, concise news from both Tapestry 5 framework and any other related tweets. - Efficiency One of the "cons" of maven sites is that they make you writing big pages and big menus. It is bad because it results in an insanely big amount of data that kills the data itself. The homepage should be efficient and concise. - References Real Tapestry applications showcase is a must have. We should be able to say "Hey, look! They've been using Tapestry in production and see how nice it works.". We already have some greats examples and we should show them.
Re: Groovy for tests?
Hi Howard,
take a look at http://spockframework.org/ a really interesting groovy
test framework
I know that one of the commiters is using it heavily to test Tapestry IOC
services
and Tapestry 5 pages.
using groovy to verify generated html is much more fun.
g,
kris
Von:Christian Edward Gruber
An: "Tapestry development"
Datum: 20.05.2010 01:41
Betreff:Re: Groovy for tests?
I think you can nicely end up with a good test-oriented DSL by using
Groovy, which should make tests nice and readable.
Christian.
On May 19, 2010, at 7:32 PM, Howard Lewis Ship wrote:
> Absolutely. This is just for some new tests I'm writing; I'm not
> talking about a wholesale change. I'm already pretty pleased with
> some of the results.
>
>
>void execute(root, resolver, closure) {
>
>replay()
>
>closure.call(new PageTemplateLocator(root, resolver))
>
>verify()
>}
>
>@Test
>void not_a_page_class() {
>def model = mockComponentModel()
>def root = mockResource()
>def resolver = mockComponentClassResolver()
>
>train_getComponentClassName(model, "foo.bar.Baz")
>
>execute (root, resolver) {
>
>assert it.locateTemplate (model, Locale.FRENCH) == null
>}
>}
>
> Using a method + closure to instantiate the object being tested and
> pass it as "it" to the closure works really well (and eliminates
> confusion about replay() and verify() ).
>
> I'm sure my Groovy skills will improve and there'll be better ways to
> do this, but not having to deal with all the variable types is already
> a step in the right direction.
>
> On Wed, May 19, 2010 at 1:13 PM, Igor Drobiazko
> wrote:
>> I guess you don't want to force all Tapestry users to switch to
>> Groovy-based
>> tests. It should be still possible to write pure java tests after the
>> upgrade to 5.2. Furthermore existing test should still work.
>>
>> However, I need a reason to improve my Groovy skills. :) So go ahead.
>>
>> On Wed, May 19, 2010 at 5:16 PM, Howard Lewis Ship
>> wrote:
>>
>>> I'd like to start experimenting with writing some of the Tapestry
>>> tests in Groovy, rather than Java. Any objections?
>>>
>>> --
>>> 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: dev-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: dev-h...@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>> http://tapestry5.de/blog
>>
>
>
>
> --
> 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: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Robin Komiwes as Tapestry Committer
+1 (non-binding) g, kris Von:"Thiago H. de Paula Figueiredo" An: "Tapestry development" Datum: 20.05.2010 04:21 Betreff:Re: [VOTE] Robin Komiwes as Tapestry Committer On Wed, 19 May 2010 22:41:54 -0300, Howard Lewis Ship wrote: > Howard M. Lewis Ship: +1 (binding) Thiago H. de Paula Figueiredo +1 (binding) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Igor Drobiazko as PMC Member
+1 (non-binding) Von:Robin Komiwes An: Tapestry development Datum: 12.05.2010 17:06 Betreff:Re: [VOTE] Igor Drobiazko as PMC Member Gesendet von: odiss...@gmail.com +1 (non-binding) On Wed, May 12, 2010 at 5:02 PM, Ben Dotte wrote: > Ben Dotte: +1 (non-binding) > > On Wed, May 12, 2010 at 1:02 AM, Dmitry Gusev > wrote: > > +1 (non-binding) > > > > On Tue, May 11, 2010 at 20:12, Howard Lewis Ship > wrote: > > > >> Given the efforts that Igor has put into Tapestry, both within the > >> code base, mentoring on the mailing list, and in book form, I think > >> it's a terrible omission that he is not a PMC member. I think it is > >> time to rectify that, and add him to the PMC where his vote will fully > >> count in all aspects of guiding the future of Tapestry. > >> > >> A +1 vote will recognize Igor as a Tapestry PMC member. > >> > >> Howard M. Lewis Ship: +1 (binding) > >> > >> -- > >> 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: dev-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: dev-h...@tapestry.apache.org > >> > >> > > > > > > -- > > Dmitry Gusev > > > > AnjLab Team > > http://anjlab.com > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: Thought experiment: shared pages/components
i agree with you on the CDI topic. but would a change, as proposed by howard, change the performance characteristics as described by http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/? would the benchmark be improved? i'd expect, that at least the memory consumption would decrease. especially when comparing with wicket, i'd like to have a unique selling proposition. before the benchmark i was always arguing - as documented - that Tapestry 5 would achieve better performance (speed, memory) characteristics because of its "static structure - dynamic behaviour" paradigm. now after the benchmark i don't see this argument hold anymore. (or maybe s so again, would such a change improve T5 in such a way we could outperform any other web framework in a certain area? g, kris "Thiago H. de Paula Figueiredo" 20.01.2010 13:55 Bitte antworten an "Tapestry development" An "Tapestry development" Kopie Thema Re: Thought experiment: shared pages/components On Wed, 20 Jan 2010 10:21:35 -0200, Piero Sartini wrote: > I think making tapestry-ioc a portable extension is the way to go. I agree. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Tapestry Release 5.1.0.7
true but i'd have to change my exisiting applications to make it work again. to be honest not a big deal, but if we say it is backwards compatible i wouldn't have to change anything ... just my two cents g, kris "Thiago H. de Paula Figueiredo" 13.01.2010 12:30 Bitte antworten an "Tapestry development" An "Tapestry development" Kopie Thema Re: [VOTE] Tapestry Release 5.1.0.7 On Wed, 13 Jan 2010 09:26:32 -0200, Kristian Marinkovic wrote: > why would someone want to block css, javascript and images only > because they are on the classpath? > i use a lot of these type of assets to modularize by web application Point taken. :) Anyway, you can block or allow anything you want adding a new rule before the default ones. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Tapestry Release 5.1.0.7
why would someone want to block css, javascript and images only because they are on the classpath? i use a lot of these type of assets to modularize by web application g, kris "Thiago H. de Paula Figueiredo" 13.01.2010 11:56 Bitte antworten an "Tapestry development" An "Tapestry development" Kopie Thema Re: [VOTE] Tapestry Release 5.1.0.7 On Wed, 13 Jan 2010 07:18:14 -0200, Ulrich Stärk wrote: > Ulrich Stärk: -1 (non-binding) > > For the same reasons and because one has to do additional configuration > in order for common assets on the context to be accessible. -1 (binding), for the reasons above. Let's reach an agreement on what the default must be. I guess most people here would agree with: Context assets: all common assets (images, CSS, JavaScript) accessible. Classpath assets: all blocked. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Tapestry Release 5.1.0.6
Kristian Marinkovic: +1 "Joachim Van der Auwera (PROGS bvba)" 24.12.2009 15:01 Bitte antworten an "Tapestry development" An Tapestry development Kopie Thema Re: [VOTE] Tapestry Release 5.1.0.6 Joachim Van der Auwera : +1 Andreas Andreou wrote: > I've created and uploaded a release of Tapestry 5.1.0.6, ready to be voted upon. > > The files are uploaded to a Maven staging repository: > > https://repository.apache.org/content/repositories/orgapachetapestry-009/ > > and to: > > http://people.apache.org/~andyhot/tapestry-releases/5.1.0.6/ > > Please examine these files to determine if a new release, 5.1.0.6, is ready. > > I've also created a 5.1.0.6 tag in Subversion: > > http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.1.0.6/ > > Th vote will run for 5 days. On a successful vote, > I'll promote the artifacts to the central repo, > move the binary / source distributions to the proper distribution directories > and send out appropriate notifications. > > Here are the release notes / changes: > > Bug > > * [TAP5-556] - Fix TranslatorSourceImplTest > * [TAP5-711] - Submit component: using image parameter brakes > "Selected" events > * [TAP5-714] - Incorrect encoding of single quotes for Ajax requests > * [TAP5-719] - Component LinkSubmit doesn't work > * [TAP5-734] - Tapestry tutorial documentation refers to old > archtype command > * [TAP5-749] - The FormFragment and LinkSubmit components create a > hidden field whose id ends with ":hidden" > * [TAP5-755] - URL rewriting documentation contains an example > that won't compile due to lack of a return value > * [TAP5-767] - PropertyConduitSourceImpl should use english locale > (instead of default locale) when evaluating decimals > * [TAP5-779] - CLONE -Linksubmit doesn't work inside a form with > Zone parameter set > * [TAP5-815] - Asset dispatcher allows any file inside the webapp > visible and downloadable > * [TAP5-868] - It is not possible to attach a validation event > listener to a Palette (or other field) > * [TAP5-894] - Fix PartialMarkupDocumentLinkerTest.stylesheet_link() > * [TAP5-896] - Contribute 'properties' file extension to the > configuration of ResourceDigestGenerator > * [TAP5-913] - java.lang.VerifyError Stack size too large > * [TAP5-936] - Tapestry wiki link links to nothing for locales other then en > > Improvement > > * [TAP5-762] - Upgrade Selenium dependencies to version 1.0.1 > * [TAP5-912] - Validation of properties of type > java.util.Collection should fail when the collection is empty > > New Feature > > * [TAP5-138] - Add Zone parameter to Select component > > Task > > * [TAP5-819] - remove ide-specific files from all sub-modules and > add them to svn:ignore > > > PS. Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > PS2. Enjoy and ... Merry Christmas > > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Ulrich Stärk as Tapestry Committer
+1 "Thiago H. de Paula Figueiredo" 22.11.2009 12:40 Bitte antworten an "Tapestry development" An "Tapestry development" Kopie Thema Re: [VOTE] Ulrich Stärk as Tapestry Committer Thiago H. de Paula Figueiredo: +1 (binding) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: url - append .html Tapestry5
if you use 5.0.18 (or lower) take a look at the LinkFactory
service. You can add an LinkFactoryListener which in
turn can add any parameter to the generated tapestry links
g
kris
Telefon +43 (0)662 4670-6676
Fax +43 (0)662 4670-16676
kristian.marinko...@porsche.co.at
Porsche Informatik Gesellschaft m.b.H. | A – 5101 Bergheim |
Handelszentrum 7
Sitz: Salzburg | FN 72830 d / Landesgericht Salzburg | DVR 88439 | UID ATU
36773309
http://www.porsche-informatik.at
"runtime.host"
18.05.2009 09:51
Bitte antworten an
"Tapestry development"
An
dev@tapestry.apache.org
Kopie
Thema
url - append .html Tapestry5
Hello.
I got the requirement for my Tapestry5 prototype that the URLs have to
look
like this:
homepage ->/home.html
change user -> /home.html?username={username}
Uff. How can I manage this problem?
--
View this message in context:
http://www.nabble.com/url---append-.html-Tapestry5-tp23592694p23592694.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Adding URL rewriting to Tapestry
hi thiago
+1
i have the same problem as described by markus. a fully
internationalized web app should also have internationalized
urls. not just urls implied by the class names.
i'd also wish to have positional parameters that i could set
on a per page/link basis. example in german below:
@URL("gebrauchtwagen/${car.id}/ausstattung/${equipment.id}")
public class CarEquipment
{
}
i think i saw something similar in seam or spring mvc.
g,
kris
Markus Joschko
05.03.2009 09:05
Bitte antworten an
"Tapestry development"
An
Tapestry development
Kopie
Thema
Re: Adding URL rewriting to Tapestry
Hi Thiago,
I think what Tapestry needs is not necessarily a complete URL
rewriting logic but a way to abstract from package and class names in
the path.
I am located in Europe and have done work for different clients in
different countries and often the clients want to have meaningful URLs
in their native language.
Given that you want to reuse the code you have (english
packages/classnames) you can only solve this by heavy URL rewriting in
apache. I think it should be the responsibility
of tapestry to provide a hook for "translations" of package and
classnames, as only this makes the i18n package complete.
Regards,
Markus
On Thu, Mar 5, 2009 at 3:06 AM, Thiago H. de Paula Figueiredo
wrote:
> Hi!
>
> As a new committer, I would like to hear what do you think about this.
> I'm working on a project that needs some URL rewriting. What about
adding
> this to Tapestry? I've been playing with it and it seems easy enough to
be
> my first issue in Tapestry. One example of open source's "scratching
your
> own itch". :) As I'll have little free time this month to work with
other
> issues, I guess this is good way to finally start contributing to
Tapestry,
> instead of just participating in the mailing list.
>
> Any thoughts? Does Tapestry really needs URL rewriting or should it be
> developed elsewhere (in Ars Machina Project, for example)?
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
[jira] Updated: (TAP5-314) issue tracking link on tapestry5 page should refer to https://issues.apache.org/jira/browse/TAP5
[ https://issues.apache.org/jira/browse/TAP5-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Marinkovic updated TAP5-314: - Priority: Trivial (was: Major) > issue tracking link on tapestry5 page should refer to > https://issues.apache.org/jira/browse/TAP5 > > > Key: TAP5-314 > URL: https://issues.apache.org/jira/browse/TAP5-314 > Project: Tapestry 5 > Issue Type: Bug > Components: documentation >Affects Versions: 5.0.15 >Reporter: Kristian Marinkovic >Priority: Trivial > > so it is easier to find from here: > http://tapestry.apache.org/tapestry5/issue-tracking.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAP5-314) issue tracking link on tapestry5 page should refer to https://issues.apache.org/jira/browse/TAP5
issue tracking link on tapestry5 page should refer to https://issues.apache.org/jira/browse/TAP5 Key: TAP5-314 URL: https://issues.apache.org/jira/browse/TAP5-314 Project: Tapestry 5 Issue Type: Bug Components: documentation Affects Versions: 5.0.15 Reporter: Kristian Marinkovic so it is easier to find from here: http://tapestry.apache.org/tapestry5/issue-tracking.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TAP5-232) invalid Encoding of ValidationMessages_de.properties
[ https://issues.apache.org/jira/browse/TAP5-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Marinkovic closed TAP5-232. Resolution: Invalid this was NOT a bug!!! removed the utf-8 filter and removed the ValidationMessages_de.properties file that was defined in an own module in a package that corresponds with the tapestry5 package (this was done as a bug fix for another/previous t5 bug) . @uli: thank you very much for your help and suggestions > invalid Encoding of ValidationMessages_de.properties > > > Key: TAP5-232 > URL: https://issues.apache.org/jira/browse/TAP5-232 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.15 > Reporter: Kristian Marinkovic >Priority: Blocker > > the encoding of the ValidationMessages_de.properties is wrong; it was correct > in 5.0.14 > everytime a validation fails the String.format() call within the Validator > will throw an exception > eg. > currently: > maximum-string-length=%2$s darf höchstens %1$d Zeichen lang sein. > should be: > maximum-string-length=Der Wert für das Feld %s darf maximal %d Zeichen lang > sein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAP5-232) invalid Encoding of ValidationMessages_de.properties
[ https://issues.apache.org/jira/browse/TAP5-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634468#action_12634468 ] Kristian Marinkovic commented on TAP5-232: -- do i have to set any parameter (T5 symbol) or vm property? > invalid Encoding of ValidationMessages_de.properties > > > Key: TAP5-232 > URL: https://issues.apache.org/jira/browse/TAP5-232 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.15 > Reporter: Kristian Marinkovic >Priority: Blocker > > the encoding of the ValidationMessages_de.properties is wrong; it was correct > in 5.0.14 > everytime a validation fails the String.format() call within the Validator > will throw an exception > eg. > currently: > maximum-string-length=%2$s darf höchstens %1$d Zeichen lang sein. > should be: > maximum-string-length=Der Wert für das Feld %s darf maximal %d Zeichen lang > sein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAP5-232) invalid Encoding of ValidationMessages_de.properties
[ https://issues.apache.org/jira/browse/TAP5-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634463#action_12634463 ] Kristian Marinkovic commented on TAP5-232: -- hi uli, i think i found a hint in the java.lang.Properties javadoc: "The load and store methods load and store properties in a simple line-oriented format specified below. This format uses the ISO 8859-1 character encoding. Characters that cannot be directly represented in this encoding can be written using Unicode escapes ; only a single 'u' character is allowed in an escape sequence. The native2ascii tool can be used to convert property files to and from other character encodings." if i recall correctly, someone on the mailinglist said tapestry5 would to the native2ascii conversion automatically... have to check this > invalid Encoding of ValidationMessages_de.properties > > > Key: TAP5-232 > URL: https://issues.apache.org/jira/browse/TAP5-232 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core > Affects Versions: 5.0.15 >Reporter: Kristian Marinkovic >Priority: Blocker > > the encoding of the ValidationMessages_de.properties is wrong; it was correct > in 5.0.14 > everytime a validation fails the String.format() call within the Validator > will throw an exception > eg. > currently: > maximum-string-length=%2$s darf höchstens %1$d Zeichen lang sein. > should be: > maximum-string-length=Der Wert für das Feld %s darf maximal %d Zeichen lang > sein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAP5-232) invalid Encoding of ValidationMessages_de.properties
[ https://issues.apache.org/jira/browse/TAP5-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634451#action_12634451 ] Kristian Marinkovic commented on TAP5-232: -- hi uli, checked our modules/projects twice and we don't have an own ValidationMessages_de.properties file. The previous _de_DE file worked good for us (deleted in 5.0.15). please compare the two files. i've just checked the other ValidationMessages in the jar and found the same problem eg. with _fr, _hr others look fine to me _fi, _sv_SE, _pt, _it what editor are you using? i'm going to assemble a small maven project later to reproduce the exception and upload it here. we are adding the @Validate annotation onto a bean field with the string "maxLength=50" and get this exception g, kris > invalid Encoding of ValidationMessages_de.properties > > > Key: TAP5-232 > URL: https://issues.apache.org/jira/browse/TAP5-232 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.15 >Reporter: Kristian Marinkovic >Priority: Blocker > > the encoding of the ValidationMessages_de.properties is wrong; it was correct > in 5.0.14 > everytime a validation fails the String.format() call within the Validator > will throw an exception > eg. > currently: > maximum-string-length=%2$s darf höchstens %1$d Zeichen lang sein. > should be: > maximum-string-length=Der Wert für das Feld %s darf maximal %d Zeichen lang > sein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAP5-232) invalid Encoding of ValidationMessages_de.properties
[ https://issues.apache.org/jira/browse/TAP5-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634438#action_12634438 ] Kristian Marinkovic commented on TAP5-232: -- hi ulrich, have looked at the .properties file in the 5.0.15 release in the svn trunk? i think it was modified by a non-utf8 editor before it was commited. anyway i think we should use utf8 characters for every non ascii character in the .properties files. eg: ö ... 00F6 g, kris > invalid Encoding of ValidationMessages_de.properties > > > Key: TAP5-232 > URL: https://issues.apache.org/jira/browse/TAP5-232 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.15 > Reporter: Kristian Marinkovic >Priority: Blocker > > the encoding of the ValidationMessages_de.properties is wrong; it was correct > in 5.0.14 > everytime a validation fails the String.format() call within the Validator > will throw an exception > eg. > currently: > maximum-string-length=%2$s darf höchstens %1$d Zeichen lang sein. > should be: > maximum-string-length=Der Wert für das Feld %s darf maximal %d Zeichen lang > sein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TAP5-232) invalid Encoding of ValidationMessages_de.properties
[ https://issues.apache.org/jira/browse/TAP5-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Marinkovic updated TAP5-232: - Description: the encoding of the ValidationMessages_de.properties is wrong; it was correct in 5.0.14 everytime a validation fails the String.format() call within the Validator will throw an exception eg. currently: maximum-string-length=%2$s darf höchstens %1$d Zeichen lang sein. should be: maximum-string-length=Der Wert für das Feld %s darf maximal %d Zeichen lang sein. was: the encoding of the ValidationMessages_de.properties is wrong; it was correct in 5.0.14 eg. currently: maximum-string-length=%2$s darf höchstens %1$d Zeichen lang sein. should be: maximum-string-length=Der Wert für das Feld %s darf maximal %d Zeichen lang sein. > invalid Encoding of ValidationMessages_de.properties > > > Key: TAP5-232 > URL: https://issues.apache.org/jira/browse/TAP5-232 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.15 > Reporter: Kristian Marinkovic >Priority: Blocker > > the encoding of the ValidationMessages_de.properties is wrong; it was correct > in 5.0.14 > everytime a validation fails the String.format() call within the Validator > will throw an exception > eg. > currently: > maximum-string-length=%2$s darf höchstens %1$d Zeichen lang sein. > should be: > maximum-string-length=Der Wert für das Feld %s darf maximal %d Zeichen lang > sein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAP5-232) invalid Encoding of ValidationMessages_de.properties
invalid Encoding of ValidationMessages_de.properties Key: TAP5-232 URL: https://issues.apache.org/jira/browse/TAP5-232 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.0.15 Reporter: Kristian Marinkovic Priority: Blocker the encoding of the ValidationMessages_de.properties is wrong; it was correct in 5.0.14 eg. currently: maximum-string-length=%2$s darf höchstens %1$d Zeichen lang sein. should be: maximum-string-length=Der Wert für das Feld %s darf maximal %d Zeichen lang sein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAP5-230) unqualified injection of DefaultHibernateConfigurer within HibernateModule provokes IOC exceptions
unqualified injection of DefaultHibernateConfigurer within HibernateModule
provokes IOC exceptions
--
Key: TAP5-230
URL: https://issues.apache.org/jira/browse/TAP5-230
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-ioc
Affects Versions: 5.0.15
Reporter: Kristian Marinkovic
the injection of the HibernateConfigurer to the HibernateSessionSource service
needs to be qualified. the ioc container creates an exception if another
service with the same interface is defined (even when fully qualified)
public static void contributeHibernateSessionSource(
OrderedConfiguration config,
HibernateConfigurer defaultHibernateConfigurer,
ObjectLocator locator)
should be:
public static void contributeHibernateSessionSource(
OrderedConfiguration config,
@Service("DefaultHibernateConfigurer") HibernateConfigurer
defaultHibernateConfigurer,
ObjectLocator locator)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-2653) enable creation of custom "onException" event handler
enable creation of custom "onException" event handler - Key: TAPESTRY-2653 URL: https://issues.apache.org/jira/browse/TAPESTRY-2653 Project: Tapestry Issue Type: Improvement Components: tapestry-core Affects Versions: 5.0.14 Reporter: Kristian Marinkovic make it possible to create custom "onException" event handler that are fired when custom Exceptions are thrown. i have the use case saying, that when an optimistic lock exception is thrown the same page with the newly loaded entity and an error message has to be displayed. Although it is possible to use the "onException" event it would be much nicer to have a "onExceptionFromOptimisticLocking" exception where the developer can put the exception handling into this specific method. In the near future we will have multiple other exceptions that need to be handled in a similar way. i prefer specific event handler to a bunch of instanceof statements -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-2647) IOC services bound using a marker behave differently than services with a serviceId thus producing a StackOverflow
IOC services bound using a marker behave differently than services with a
serviceId thus producing a StackOverflow
--
Key: TAPESTRY-2647
URL: https://issues.apache.org/jira/browse/TAPESTRY-2647
Project: Tapestry
Issue Type: Bug
Components: tapestry-ioc
Affects Versions: 5.0.14
Reporter: Kristian Marinkovic
Attachments: test.zip
the module class below produces a StackOverflow if i try to call the chain. if
i use a serviceId instead of the marker annotation everything work as expected.
it seems, that a marker annotation does not have the same behaviour as a
serviceId. see also the attached maven project that examplifies the problem.
public final class StackOverflowModule
{
public static void bind(ServiceBinder binder)
{
binder.bind(ChainInterface.class,
HelloWorld.class).withMarker(Default.class);
}
public ChainInterface buildChainInterface(List
chainItems, ChainBuilder builder)
{
return builder.build(ChainInterface.class, chainItems);
}
public void
contributeChainInterface(OrderedConfiguration chainItems,
@Default ChainInterface helloWorld)
{
chainItems.add("Default", helloWorld);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TAPESTRY-2647) IOC services bound using a marker behave differently than services with a serviceId thus producing a StackOverflow
[
https://issues.apache.org/jira/browse/TAPESTRY-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Marinkovic updated TAPESTRY-2647:
--
Attachment: test.zip
example maven/eclipse project
> IOC services bound using a marker behave differently than services with a
> serviceId thus producing a StackOverflow
> --
>
> Key: TAPESTRY-2647
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2647
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-ioc
>Affects Versions: 5.0.14
>Reporter: Kristian Marinkovic
> Attachments: test.zip
>
>
> the module class below produces a StackOverflow if i try to call the chain.
> if i use a serviceId instead of the marker annotation everything work as
> expected. it seems, that a marker annotation does not have the same behaviour
> as a serviceId. see also the attached maven project that examplifies the
> problem.
> public final class StackOverflowModule
> {
> public static void bind(ServiceBinder binder)
> {
> binder.bind(ChainInterface.class,
> HelloWorld.class).withMarker(Default.class);
> }
>
> public ChainInterface buildChainInterface(List
> chainItems, ChainBuilder builder)
> {
> return builder.build(ChainInterface.class, chainItems);
> }
>
> public void
> contributeChainInterface(OrderedConfiguration chainItems,
> @Default ChainInterface helloWorld)
> {
> chainItems.add("Default", helloWorld);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-2460) Nested BeanEditors (where the block parameter for a property to one BeanEditor contains another BeanEditor) results in a StackOverflowException
[ https://issues.apache.org/jira/browse/TAPESTRY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620148#action_12620148 ] Kristian Marinkovic commented on TAPESTRY-2460: --- hi Martin, i'm glad someone else experiences the same problem :) have you found a workaround? g, kris > Nested BeanEditors (where the block parameter for a property to one > BeanEditor contains another BeanEditor) results in a StackOverflowException > --- > > Key: TAPESTRY-2460 > URL: https://issues.apache.org/jira/browse/TAPESTRY-2460 > Project: Tapestry > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.13 >Reporter: Kristian Marinkovic >Assignee: Howard M. Lewis Ship > Fix For: 5.0.14 > > Attachments: beaneditor.zip > > > the eclipse/maven example project shows how a StackOverflowException is > thrown if a Form is submitted that contains a BeanEditor that itself contains > another BeanEditor. However the initial display works perfectly. > somehow i suspect the PropertyConduits to be responsible because two of them > produce the infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 double click / multiple windows on same session prevention
i think it depends on the application, whether double clicks are allowed or not. my simple solution: attach a Mixin to every ActionLink component where double clicks are not allowed. This mixin renders some javascript capturing the link's click event (javascript events -> prototype observe). in the event listener i then disable the link by adding a dummy event listener that captures all other click events. there are some cases not covered - especially when dealing with AJAX - but most of the time this solution is sufficient g, kris 9902468 <[EMAIL PROTECTED]> 05.08.2008 13:51 Bitte antworten an "Tapestry development" An dev@tapestry.apache.org Kopie Thema Re: T5 double click / multiple windows on same session prevention Dear list: I would really like to hear your take on this matter? Has this been discussed before regarding T5? Is there alternative, better way to stop double clicks etc? Should I just add Jira: "Make Tapestry ignore double clicks"? - 99 9902468 wrote: > > Hi! > > In an effort to make J2EE and browsers suck less :) Tapestry should really > implement some mechanism to prevent double clicks and all problems related > to multiple windows using the same session / back button etc. > > I'm familiar with Struts kind approach with tokens, and I am proposing > similar approach that should be implemented to Tapestry. > > The implementation involves filter that intercepts all requests, > synchronizes them to session, and checks the tokens submitted. > > The used method is generic, as it is based on filter that captures > requests and basically works as specified: > > - Check that the token that came with the request matches the token in > session > - If no token is associated -> process request as it is processed > currently > - If token exists but doesn't match -> Show error page / developer > configurable action is taken > - Start processing request. > - If another request is submitted with the same token and session -> > capture the response to session > - When request processing is complete -> populate the latest response > with the response returned if there is one in session > - Return the response > > The usage of session can probably be at least partially avoided using > Tapestry's facilities. This should also be configurable as there is > overhead associated to this process. > > What needs to be altered in Tapestry? > - The addition of the filter (In chain only if this functionality is > enabled) > - Perhaps some service that encapsulates some of the logic? > - Form should be altered to include the token to the submit (If this > functionality is enabled) > - Action Event etc links should add the token to request url (If this > functionality is enabled) > - New configuration symbol with values > (SymbolConstants.UNIQUE_REQUEST_SUPPORT): > - off (default, everything as it is now) > - forgiving (requests without tokens are processed the same way when > off) > - strict-forms (forms are required to have correct token, else as if > token exists but doesn't match) > - strict-links (links are required to have correct token, else as if > token exists but doesn't match) > - strict (forms and links are required to have correct token, else as > if token exists but doesn't match) > > I do not have enough knowledge how this can be implemented AJAX wise, but > I do know that this should really be corrected. > > I'm ready to contribute to this if I can. Please elaborate. > > - 99 > -- View this message in context: http://www.nabble.com/T5-double-click---multiple-windows-on-same-session-prevention-tp18807447p18829465.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (TAPESTRY-2460) Nested BeanEditors (where the block parameter for a property to one BeanEditor contains another BeanEditor) results in a StackOverflowException
[ https://issues.apache.org/jira/browse/TAPESTRY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615114#action_12615114 ] kristian edited comment on TAPESTRY-2460 at 7/20/08 1:03 PM: hi howard, this problem is still present in the latest svn version (678315) was (Author: kristian): hi howard, this problem is still present in latest svn version (678315) > Nested BeanEditors (where the block parameter for a property to one > BeanEditor contains another BeanEditor) results in a StackOverflowException > --- > > Key: TAPESTRY-2460 > URL: https://issues.apache.org/jira/browse/TAPESTRY-2460 > Project: Tapestry > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.13 >Reporter: Kristian Marinkovic >Assignee: Howard M. Lewis Ship > Fix For: 5.0.14 > > Attachments: beaneditor.zip > > > the eclipse/maven example project shows how a StackOverflowException is > thrown if a Form is submitted that contains a BeanEditor that itself contains > another BeanEditor. However the initial display works perfectly. > somehow i suspect the PropertyConduits to be responsible because two of them > produce the infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-2460) Nested BeanEditors (where the block parameter for a property to one BeanEditor contains another BeanEditor) results in a StackOverflowException
[ https://issues.apache.org/jira/browse/TAPESTRY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615114#action_12615114 ] Kristian Marinkovic commented on TAPESTRY-2460: --- hi howard, this problem is still present in latest svn version (678315) > Nested BeanEditors (where the block parameter for a property to one > BeanEditor contains another BeanEditor) results in a StackOverflowException > --- > > Key: TAPESTRY-2460 > URL: https://issues.apache.org/jira/browse/TAPESTRY-2460 > Project: Tapestry > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.13 >Reporter: Kristian Marinkovic >Assignee: Howard M. Lewis Ship > Fix For: 5.0.14 > > Attachments: beaneditor.zip > > > the eclipse/maven example project shows how a StackOverflowException is > thrown if a Form is submitted that contains a BeanEditor that itself contains > another BeanEditor. However the initial display works perfectly. > somehow i suspect the PropertyConduits to be responsible because two of them > produce the infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anyone ready for 5.0.14?
hi howard, issue https://issues.apache.org/jira/browse/TAPESTRY-2460 is not resolved. i've testes it with the latest tapestry version from the trunk with no luck (using the attached tapestry/maven project)... therefore i reopened it. if i had a vote i'd say: -1 g, kris "Jesse Kuhnert" <[EMAIL PROTECTED]> 03.07.2008 05:09 Bitte antworten an "Tapestry development" An "Tapestry development" Kopie Thema Re: Anyone ready for 5.0.14? I'm not sure what words of wisdom I could share but I do sort of see both sides of this, I think my best experience with a similar situation was when I spent a few weeks mulling over some ideas for some jini stuff and shared them with what is probably my first big software mentor and was told that "I'm free to implement them, just don't get mad if you have to throw it all out". I didn't have to throw ~all~ of it out, but I certainly was corrected in a number of things. At the end of the day, despite his project management warts and all the typical framework competitive posturing bullshit that everyone goes through - Howard really is one of the most gifted software designers I've had the pleasure to work with. So, be prepared to be shot down but also know that the knowledge you gain from the explanations of why what you are doing won't work isn't something you are very likely to come across in your day to day development activities. You won't find many opportunities to flex these kinds of designs muscles that will impact more than a couple people on your development group for however long the product incarnation you are working on lasts. This stuff lasts much longer and has a much bigger impact on people and your general understanding of how/why API development works. Start small and work your way out. There's nothing lost in being wrong, just in not learning something new. On Wed, Jul 2, 2008 at 6:30 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > Its a problem for me. If Tapestry were a project at Formos, not at > Apache, I would have a team, we would agree on dates and deliverables, > etc. People would be responsible for what they are assigned, or take > on. > > What pains me is that many people have ideas about what needs to be > done, sometimes very vocal ideas, but that's as far as it goes. > > The structure of the code (components and IoC services) should make it > reasonable for people to "set up shop" in a specific area, as you > describe. It just isn't happening. > > For every trivial bug that I end up fixing, it's one less critical bug > I can take on. And when, like now, I'm client focused (preparing for > several days of training), not much is going to happen. > > > On Wed, Jul 2, 2008 at 3:11 PM, Ben Dotte <[EMAIL PROTECTED]> wrote: >> Perhaps I am just naive to the way open source software is supposed to >> be written, but it has always struck me as odd that particular areas >> of the framework aren't divvied out to specific committers, or maybe >> even groups of committers, to work on. I like to feel responsible for >> a particular segment of a codebase, it encourages me to fix bugs in >> that area and I feel like I have some level of control over the >> general design of that area. >> >> I'm not saying I in particular want to be assigned an area--a new baby >> and my job keep me plenty busy these days :) Not much time for >> Tapestry, unfortunately. >> >> Something like that probably really needs to happen earlier in the >> project though, when there is still enough of the core architecture >> available to be designed. >> >> Just my 2 cents.. I'm not trying to be critical of Tapestry, it is and >> has been a wonderful framework. But I think it is something worth >> discussing if you are wondering why people aren't as interested in >> contributing as you would like. >> >> "I hate to be a nag, but I haven't been seeing a lot of commit activity >> from everyone else. That's very troublesome, and I'm concerned it >> reflects on my management style of the project. If you have any >> criticism, feel free to respond here or privately to me. I won't be >> offended --- I already recognize that project management is by far my >> weakest skill!" >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry / OGNL / Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (TAPESTRY-2460) Nested BeanEditors (where the block parameter for a property to one BeanEditor contains another BeanEditor) results in a StackOverflowException
[ https://issues.apache.org/jira/browse/TAPESTRY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607392#action_12607392 ] kristian edited comment on TAPESTRY-2460 at 6/23/08 2:59 PM: hi howard, i tested my beaneditor example with the latest codebase (svn 670759 and 670748) and i still got the same StackOverflowException. My test tries to simulate an example where the second BeanEditor receives its data from a PropertyEditContext object. it cannot access the child property directly because the block is defined in another page that contributes the required Blocks. i was not able to track down the problem myself, but i guess the problem is that the first BeanEditors' PropertyEditor passes the object to the PropertyEditContext by creating a conduit. Then the second BeanEditor tries to pass in the object as well by creating another conduit. and somehow the first conduit starts pointing to the second conduit (or the other way round). when i then submit the form the BeanEditor will try to read the object parameter by reading the conduit and thus starting the loop. As said, its just a guess. I already took a look at the cache inside the PropertyConduitSource but couldn't find anything. below is the stack trace i get g, kris // the beginning of the stack trace is different # rg.apache.tapestry5.ioc.util.CaseInsensitiveMap.caseInsenitiveHashCode(CaseInsensitiveMap.java:485) # org.apache.tapestry5.ioc.util.CaseInsensitiveMap.select(CaseInsensitiveMap.java:390) # org.apache.tapestry5.ioc.util.CaseInsensitiveMap.get(CaseInsensitiveMap.java:367) # org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.getBinding(InternalComponentResourcesImpl.java:284) # org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.isBound(InternalComponentResourcesImpl.java:158) # org.apache.tapestry5.corelib.components.BeanEditor._$read_parameter_object(BeanEditor.java) # org.apache.tapestry5.corelib.components.BeanEditor.getObject(BeanEditor.java:142) # org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:53) # org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.readParameter(InternalComponentResourcesImpl.java:237) # org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.readParameter(InternalComponentResourcesImpl.java:252) # org.apache.tapestry5.corelib.components.PropertyEditor._$read_parameter_object(PropertyEditor.java) # org.apache.tapestry5.corelib.components.PropertyEditor.access$2(PropertyEditor.java:86) # org.apache.tapestry5.corelib.components.PropertyEditor$1.getPropertyValue(PropertyEditor.java:166) # org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:53) # org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.readParameter(InternalComponentResourcesImpl.java:237) # org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.readParameter(InternalComponentResourcesImpl.java:252) # org.apache.tapestry5.corelib.components.BeanEditor._$read_parameter_object(BeanEditor.java) # org.apache.tapestry5.corelib.components.BeanEditor.getObject(BeanEditor.java:142) # org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:53) # org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.readParameter(InternalComponentResourcesImpl.java:237) # org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.readParameter(InternalComponentResourcesImpl.java:252) # org.apache.tapestry5.corelib.components.PropertyEditor._$read_parameter_object(PropertyEditor.java) # org.apache.tapestry5.corelib.components.PropertyEditor.access$2(PropertyEditor.java:86) # org.apache.tapestry5.corelib.components.PropertyEditor$1.getPropertyValue(PropertyEditor.java:166) # org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:53) > Nested BeanEditors (where the block parameter for a property to one > BeanEditor contains another BeanEditor) results in a StackOverflowException > --- > > Key: TAPESTRY-2460 > URL: https://issues.apache.org/jira/browse/TAPESTRY-2460 > Project: Tapestry > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.13 >Reporter: Kristian Marinkovic >Assignee: Howard M. Lewis Ship > Fix For: 5.0.14 > > Attachments: beaneditor.zip > > > the eclipse/maven example project shows how a StackOverflowException is > thrown if a Form is submitted that contains a BeanEditor that itself contains > another BeanEditor. However the initial display works perfectly. >
[jira] Reopened: (TAPESTRY-2460) Nested BeanEditors (where the block parameter for a property to one BeanEditor contains another BeanEditor) results in a StackOverflowException
[ https://issues.apache.org/jira/browse/TAPESTRY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Marinkovic reopened TAPESTRY-2460: --- > Nested BeanEditors (where the block parameter for a property to one > BeanEditor contains another BeanEditor) results in a StackOverflowException > --- > > Key: TAPESTRY-2460 > URL: https://issues.apache.org/jira/browse/TAPESTRY-2460 > Project: Tapestry > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.13 >Reporter: Kristian Marinkovic >Assignee: Howard M. Lewis Ship > Fix For: 5.0.14 > > Attachments: beaneditor.zip > > > the eclipse/maven example project shows how a StackOverflowException is > thrown if a Form is submitted that contains a BeanEditor that itself contains > another BeanEditor. However the initial display works perfectly. > somehow i suspect the PropertyConduits to be responsible because two of them > produce the infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-2470) Wrong error message: [ERROR] Uebersicht Embedded component(s) kopf are defined within component class .....pages.Uebersicht, but are not present in the component temp
[
https://issues.apache.org/jira/browse/TAPESTRY-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606684#action_12606684
]
Kristian Marinkovic commented on TAPESTRY-2470:
---
hi fritz,
i don't think this is a bug. it is correct and expected behavior.
if you use T5 there are several ways to use and to declare components: see
http://tapestry.apache.org/tapestry5/tapestry-core/guide/templates.html
if you declare a component using the @Component annotation T5 expects
that there is a t:id attribute in the template with the name of the field (or a
explicitly
set id) or it will throw an exception.
see
http://tapestry.apache.org/tapestry5/tapestry-core/guide/component-classes.html
what you did is to declare the same component twice: first using "invisible
instrumentation"
and then using the @Component annotation without a corresponding t:id (thats
what the
error message is saying).
Furthermore, just imagine what it would be if you used your component twice in
your template
using the @Component annotation with only the type attribute. How could T5
distinguish them then?
> Wrong error message: [ERROR] Uebersicht Embedded component(s) kopf are
> defined within component class .pages.Uebersicht, but are not present in
> the component template.
> ---
>
> Key: TAPESTRY-2470
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2470
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.0.13
>Reporter: Fritz Pröbstle
>Priority: Minor
>
> Abstract: Error message not correct
> Workaround: Specify t:id for the component
> Problem: Wrong error message confuses user
> Description:
> I have a Page Uebersicht with uses a Component "common/kopf" by specifiing
> only t:type="common/kopf" with *NO* t:id .
> --
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";
> body_id="literal:startseite"
> >
> page is empty
>
> ---
> In the Page-class I reference the "common/Kopf" by type , which works *BUT*
> generates the following error:
> [ERROR] Uebersicht Embedded component(s) kopf are defined within component
> class .pages.Uebersicht, but are not present in the component template.
>
> public class Uebersicht {
>
>
> @Component ( type="common/kopf")
> private Kopf kopf;
> ...
> }
> ---
> The error generation is emitted by
> PageLoaderProcessor.loadTemplateForComponent ( see my comments inside the
> code below )
>
> for (String id : loadingComponentModel.getEmbeddedComponentIds())
> // getEmbeddedComponentIds returns {"kopf"}
>
> // -I expect it to return {"common/kopf" } for a
> component in the subpackage "common" of the "tapestry.app-package"
> embeddedIds.put(id, true);
> idAllocator.clear();
> for (String id : template.getComponentIds()) // getComponentIds
> returns *ONLY* ids which are explictly set by t:id- implicit id which are
> derived from t::type are missing
>
> // in this case I expect "common/kopf" inside the result
> {
> idAllocator.allocateId(id);
> embeddedIds.remove(id);
> }
> if (!embeddedIds.isEmpty())
>
> logger.error(ServicesMessages.embeddedComponentsNotInTemplate(embeddedIds.keySet(),
> componentClassName));
> ---
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-2460) a BeanEditor contributed through a Block to another BeanEditor creates StackOverflowException when submitted
a BeanEditor contributed through a Block to another BeanEditor creates StackOverflowException when submitted Key: TAPESTRY-2460 URL: https://issues.apache.org/jira/browse/TAPESTRY-2460 Project: Tapestry Issue Type: Bug Components: tapestry-core Reporter: Kristian Marinkovic Fix For: 5.0.14 Attachments: beaneditor.zip the eclipse/maven example project shows how a StackOverflowException is thrown if a Form is submitted that contains a BeanEditor that itself contains another BeanEditor. However the initial display works perfectly. somehow i suspect the PropertyConduits to be responsible because two of them produce the infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TAPESTRY-2460) a BeanEditor contributed through a Block to another BeanEditor creates StackOverflowException when submitted
[ https://issues.apache.org/jira/browse/TAPESTRY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Marinkovic updated TAPESTRY-2460: -- Fix Version/s: (was: 5.0.14) Affects Version/s: 5.0.13 removed fix version :) > a BeanEditor contributed through a Block to another BeanEditor creates > StackOverflowException when submitted > > > Key: TAPESTRY-2460 > URL: https://issues.apache.org/jira/browse/TAPESTRY-2460 > Project: Tapestry > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.13 >Reporter: Kristian Marinkovic > Attachments: beaneditor.zip > > > the eclipse/maven example project shows how a StackOverflowException is > thrown if a Form is submitted that contains a BeanEditor that itself contains > another BeanEditor. However the initial display works perfectly. > somehow i suspect the PropertyConduits to be responsible because two of them > produce the infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TAPESTRY-2460) a BeanEditor contributed through a Block to another BeanEditor creates StackOverflowException when submitted
[ https://issues.apache.org/jira/browse/TAPESTRY-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Marinkovic updated TAPESTRY-2460: -- Attachment: beaneditor.zip example project with BeanEditor containing another BeanEditor > a BeanEditor contributed through a Block to another BeanEditor creates > StackOverflowException when submitted > > > Key: TAPESTRY-2460 > URL: https://issues.apache.org/jira/browse/TAPESTRY-2460 > Project: Tapestry > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.0.13 >Reporter: Kristian Marinkovic > Attachments: beaneditor.zip > > > the eclipse/maven example project shows how a StackOverflowException is > thrown if a Form is submitted that contains a BeanEditor that itself contains > another BeanEditor. However the initial display works perfectly. > somehow i suspect the PropertyConduits to be responsible because two of them > produce the infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TAPESTRY-2030) creating a service for contribution services to the Environment service
[
https://issues.apache.org/jira/browse/TAPESTRY-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Marinkovic closed TAPESTRY-2030.
-
Resolution: Fixed
i consider this jira closed through the advent of the
EnvironmentalShadowBuilder.
> creating a service for contribution services to the Environment service
> ---
>
> Key: TAPESTRY-2030
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2030
> Project: Tapestry
> Issue Type: New Feature
>Affects Versions: 5.0.8
> Reporter: Kristian Marinkovic
>Priority: Trivial
>
> each time a new (global for one page rendering) service is needed i have to
> implement MarkupRendererFilter and contributed it to the MarkupRenderer
> service. it would be more convenient to have a service that adds contributed
> services directly to the environment.
> now:
> public void
> contributeMarkupRenderer(OrderedConfiguration
> configuration,
> final MenuManager menuManager, final Environment environment) {
> configuration.add("menuManager", new MarkupRendererFilter() {
> public void renderMarkup(MarkupWriter writer, MarkupRenderer
> renderer) {
>
> environment.push(MenuManager.class, menuManager);
>
> renderer.renderMarkup(writer);
>
> environment.pop(MenuManager.class);
>
> }}, "after:heartbeat");
> }
> more convenient:
> contributeEnvironment(Configuration conf,MenuManager menuManager) {
> conf.add(MenuManager.class,menuManager);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-2458) define DefaultHibernateConfigurer as IOC service for easier override
define DefaultHibernateConfigurer as IOC service for easier override
Key: TAPESTRY-2458
URL: https://issues.apache.org/jira/browse/TAPESTRY-2458
Project: Tapestry
Issue Type: Improvement
Components: tapestry-hibernate
Affects Versions: 5.0.13
Reporter: Kristian Marinkovic
Priority: Minor
when the DefaultHibernateConfigurer is calling configuration.configure()
Hibernate will try to initialize the SessionFactory using a hibernate.cfg.xml
file from the root classpath. there are two problems to this approach: 1) you
always have to have a (dummy) hibernate.cfg.xml file in your root classpath and
2) you have to contribute another HibernateConfigurer ("after:Default") that
will call configuration.configure("myhibernate.cfg.xml") to override the first
call.
Therefore i'd suggest to make the DefaultHibernateConfigurer exchangeable by
defining it as IOC service. this would make it possible to define an own
DefaultHibernateConfigurer using the Alias service.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: IncludeJavaScriptLibrary 5.0.12 problem
see https://issues.apache.org/jira/browse/TAPESTRY-2364 g, kris stuffhere <[EMAIL PROTECTED]> 16.05.2008 10:57 Bitte antworten an "Tapestry development" An dev@tapestry.apache.org Kopie Thema IncludeJavaScriptLibrary 5.0.12 problem Hi I've recently changed the version of tapestry I'm using to 5.0.12 (snapshot) from 5.0.11 and am having some issues with the IncludeJavaScriptLibrary annotation. Originally javascript was being included in the head of the page, but since the change to 5.0.12 it is now being included at the end of the body of the page (meaning a lot of the site has stopped working). Is this a conscious change and if so is there any way to force tapestry to include the scripts in the head? Thanks -- View this message in context: http://www.nabble.com/IncludeJavaScriptLibrary-5.0.12-problem-tp17270362p17270362.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TAPESTRY-2242) Tapestry IOC StrategyBuilder should be able to create a Strategy for generic Class parameters
[
https://issues.apache.org/jira/browse/TAPESTRY-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Marinkovic closed TAPESTRY-2242.
-
Resolution: Invalid
it is not possible to implement my wish using Java 5/6 generics because type
erasure will erase any type information at runtime. maybe in java 7 or 8 :)
> Tapestry IOC StrategyBuilder should be able to create a Strategy for generic
> Class parameters
> -
>
> Key: TAPESTRY-2242
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2242
> Project: Tapestry
> Issue Type: Wish
> Components: tapestry-ioc
>Affects Versions: 5.0.11
>Reporter: Kristian Marinkovic
>
> it is not possible to create a strategy for an interface that contains a
> method with a generic Class as parameter
> the example below will create an exception if getModel(...) of the created
> Strategy object is called
> public interface MLSelectModelFactory() {
> SelectModel getModel(Class clazz);
> }
> public MLSelectModelFactory build(StrategyBuilder builder,
> Map configuration) {
>
>StrategyRegistry registry =
>StrategyRegistry.newInstance(MLSelectModelFactory.class,
> configuration);
>
> return builder.build(registry);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-2276) Required validation fails when used with select and blankOption="ALWAYS"
[
https://issues.apache.org/jira/browse/TAPESTRY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580016#action_12580016
]
Kristian Marinkovic commented on TAPESTRY-2276:
---
this issue was solved by https://issues.apache.org/jira/browse/TAPESTRY-2260
> Required validation fails when used with select and blankOption="ALWAYS"
>
>
> Key: TAPESTRY-2276
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2276
> Project: Tapestry
> Issue Type: Bug
>Affects Versions: 5.0.11
>Reporter: Ernest Monklitch
> Fix For: 5.0.12
>
>
> I have drop down defined like this:
> label="message:orient.admin.entity.manufacturer.edit.country"
> t:id="countrySelectDrop" t:value="manufacturer.country.id"
> t:validate="required" blankLabel="message:select-blanklabel"
> blankOption="ALWAYS">
> I thought that this should produce the normal "You must provide value for
> x." notification, but it results in type coersion error
> (manufacturer.counrty.id is Integer.)
> It seems that the coersion happens before required validation and in select
> one only catches ValidationException.
> try
> {
> _fieldValidationSupport.validate(selectedValue, _resources,
> _validate);
> _value = selectedValue;
> }
> catch (ValidationException ex)
> {
> _tracker.recordError(this, ex.getMessage());
> }
> Is this a bug or am I missing something obvious?
> StackTrace:
> # java.lang.NumberFormatException
> For input string: ""
> Stack trace
> *
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> * java.lang.Long.parseLong(Long.java:424)
> * java.lang.Long.(Long.java:671)
> *
> org.apache.tapestry.ioc.services.TapestryIOCModule$7.coerce(TapestryIOCModule.java:159)
> *
> org.apache.tapestry.ioc.services.TapestryIOCModule$7.coerce(TapestryIOCModule.java:157)
> *
> org.apache.tapestry.ioc.services.CoercionTuple$CoercionWrapper.coerce(CoercionTuple.java:54)
> *
> org.apache.tapestry.ioc.internal.services.CompoundCoercion.coerce(CompoundCoercion.java:46)
> *
> org.apache.tapestry.ioc.internal.services.TypeCoercerImpl.coerce(TypeCoercerImpl.java:126)
> *
> org.apache.tapestry.internal.services.TypeCoercedValueEncoderFactory$1.toValue(TypeCoercedValueEncoderFactory.java:45)
> *
> org.apache.tapestry.corelib.components.Select.processSubmission(Select.java:146)
> *
> org.apache.tapestry.corelib.base.AbstractField.processSubmission(AbstractField.java:184)
> *
> org.apache.tapestry.corelib.base.AbstractField.access$100(AbstractField.java:33)
> *
> org.apache.tapestry.corelib.base.AbstractField$ProcessSubmissionAction.execute(AbstractField.java:97)
> *
> org.apache.tapestry.corelib.base.AbstractField$ProcessSubmissionAction.execute(AbstractField.java:91)
> *
> org.apache.tapestry.corelib.components.Form.executeStoredActions(Form.java:405)
> * org.apache.tapestry.corelib.components.Form.onAction(Form.java:331)
> *
> org.apache.tapestry.corelib.components.Form.dispatchComponentEvent(Form.java)
> *
> org.apache.tapestry.internal.structure.ComponentPageElementImpl.dispatchEvent(ComponentPageElementImpl.java:851)
> *
> org.apache.tapestry.internal.structure.ComponentPageElementImpl.triggerContextEvent(ComponentPageElementImpl.java:1004)
> *
> org.apache.tapestry.internal.services.ComponentEventRequestHandlerImpl.handle(ComponentEventRequestHandlerImpl.java:67)
> *
> org.apache.tapestry.internal.services.ImmediateActionRenderResponseFilter.handle(ImmediateActionRenderResponseFilter.java:42)
> *
> org.apache.tapestry.internal.services.AjaxFilter.handle(AjaxFilter.java:42)
> *
> org.apache.tapestry.services.TapestryModule$40.handle(TapestryModule.java:2110)
> *
> org.apache.tapestry.internal.services.ComponentEventDispatcher.dispatch(ComponentEventDispatcher.java:135)
> *
> org.apache.tapestry.services.TapestryModule$13.service(TapestryModule.java:944)
> * com.orient.webshop.services.AppModule$1.service(AppModule.java:76)
> * com.orient.webshop.services.AppModule$3.service(AppModule.java:128)
> *
> org.apache.tapestry.internal.services.LocalizationFilter.service(LocalizationFilter.java:42)
> *
[jira] Commented: (TAPESTRY-2254) ValueEncoders created by HibernateEntityValueEncoder produces exceptions on empty clientValue
[
https://issues.apache.org/jira/browse/TAPESTRY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579091#action_12579091
]
Kristian Marinkovic commented on TAPESTRY-2254:
---
this issue was partly solved by
https://issues.apache.org/jira/browse/TAPESTRY-2260
> ValueEncoders created by HibernateEntityValueEncoder produces exceptions on
> empty clientValue
> -
>
> Key: TAPESTRY-2254
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2254
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-hibernate
>Affects Versions: 5.0.12
>Reporter: Kristian Marinkovic
>Priority: Critical
>
> the toValue() method of the ValueEncoder created by the
> HibernateEntityValueEncoder service tries coercing the clientValue to the
> primary key field type even if it is empty. this creates a coercion
> exception.
> public E toValue(String clientValue) {
> Class idType = _idGetter.getReturnType();
> // cannot coerce if clientValue is empty
> Object id = _typeCoercer.coerce(clientValue, idType);
> Serializable ser = Defense.cast(id, Serializable.class, "id");
> return (E)_session.get(_entityClass, ser);
> }
> the created ValueEncoder should return null if the client Value is empty/null
> this situation arises when a select component is submitted with the blank
> option selected (see blankOption parameter of select component). as long as
> there is no required validator associated with the select box null is a valid
> value (a list of entities is used for the SelectModel).
> furthermore there is no way to override/decorate the
> HibernateEntityValueEncoder nor to exclude certain entities from having
> ValueEncoders created. this is useful when custom ValueEncoders are provided.
> in existing applications the custom ValueEncoders for the entities are
> quietly ignored.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-2254) ValueEncoders created by HibernateEntityValueEncoder produces exceptions on empty clientValue
ValueEncoders created by HibernateEntityValueEncoder produces exceptions on
empty clientValue
-
Key: TAPESTRY-2254
URL: https://issues.apache.org/jira/browse/TAPESTRY-2254
Project: Tapestry
Issue Type: Bug
Components: tapestry-hibernate
Affects Versions: 5.0.12
Reporter: Kristian Marinkovic
Priority: Critical
the toValue() method of the ValueEncoder created by the
HibernateEntityValueEncoder service tries coercing the clientValue to the
primary key field type even if it is empty. this creates a coercion exception.
public E toValue(String clientValue) {
Class idType = _idGetter.getReturnType();
// cannot coerce if clientValue is empty
Object id = _typeCoercer.coerce(clientValue, idType);
Serializable ser = Defense.cast(id, Serializable.class, "id");
return (E)_session.get(_entityClass, ser);
}
the created ValueEncoder should return null if the client Value is empty/null
this situation arises when a select component is submitted with the blank
option selected (see blankOption parameter of select component). as long as
there is no required validator associated with the select box null is a valid
value (a list of entities is used for the SelectModel).
furthermore there is no way to override/decorate the
HibernateEntityValueEncoder nor to exclude certain entities from having
ValueEncoders created. this is useful when custom ValueEncoders are provided.
in existing applications the custom ValueEncoders for the entities are quietly
ignored.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-2253) Required Validator can produce NullPointerExceptions
Required Validator can produce NullPointerExceptions
Key: TAPESTRY-2253
URL: https://issues.apache.org/jira/browse/TAPESTRY-2253
Project: Tapestry
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.0.12
Reporter: Kristian Marinkovic
the validate method of the Required validator contains following code line:
if (value == null || value.toString().equals(""))...
if the toString method returns null an exception will occur (happened to me
accidentally :))
this code line should at least be changed to:
if (value == null || "".equals(value.toString())... to prevent NPE
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TAPESTRY-2242) Tapestry IOC StrategyBuilder should be able to create a Strategy for generic Class parameters
[
https://issues.apache.org/jira/browse/TAPESTRY-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Marinkovic updated TAPESTRY-2242:
--
Component/s: tapestry-ioc
Issue Type: Wish (was: Improvement)
> Tapestry IOC StrategyBuilder should be able to create a Strategy for generic
> Class parameters
> -
>
> Key: TAPESTRY-2242
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2242
> Project: Tapestry
> Issue Type: Wish
> Components: tapestry-ioc
>Affects Versions: 5.0.11
>Reporter: Kristian Marinkovic
>
> it is not possible to create a strategy for an interface that contains a
> method with a generic Class as parameter
> the example below will create an exception if getModel(...) of the created
> Strategy object is called
> public interface MLSelectModelFactory() {
> SelectModel getModel(Class clazz);
> }
> public MLSelectModelFactory build(StrategyBuilder builder,
> Map configuration) {
>
>StrategyRegistry registry =
>StrategyRegistry.newInstance(MLSelectModelFactory.class,
> configuration);
>
> return builder.build(registry);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-2242) Tapestry IOC StrategyBuilder should be able to create a Strategy for generic Class parameters
Tapestry IOC StrategyBuilder should be able to create a Strategy for generic
Class parameters
-
Key: TAPESTRY-2242
URL: https://issues.apache.org/jira/browse/TAPESTRY-2242
Project: Tapestry
Issue Type: Improvement
Affects Versions: 5.0.11
Reporter: Kristian Marinkovic
it is not possible to create a strategy for an interface that contains a method
with a generic Class as parameter
the example below will create an exception if getModel(...) of the created
Strategy object is called
public interface MLSelectModelFactory() {
SelectModel getModel(Class clazz);
}
public MLSelectModelFactory build(StrategyBuilder builder,
Map configuration) {
StrategyRegistry registry =
StrategyRegistry.newInstance(MLSelectModelFactory.class,
configuration);
return builder.build(registry);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-2230) add a contructor with page class as parameter to BeanBlockContribution
add a contructor with page class as parameter to BeanBlockContribution
--
Key: TAPESTRY-2230
URL: https://issues.apache.org/jira/browse/TAPESTRY-2230
Project: Tapestry
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.0.11
Reporter: Kristian Marinkovic
this would enable type safe programming:
instead of:
configuration.add(new
BeanBlockContribution("dealerType","DealerTypePropertyBlock","dealerType",true));
or
configuration.add(new BeanBlockContribution("dealerType",
resolver.resolvePageClassNameToPageName(DealerTypePropertyBlock.class.getName()),"dealerType",true));
this would be better and shorter (also in case of refactoring):
configuration.add(new
BeanBlockContribution("dealerType",DealerTypePropertyBlock.class,"dealerType",true));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-1764) provide access to component parameters from within mixins
[ https://issues.apache.org/jira/browse/TAPESTRY-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568625#action_12568625 ] Kristian Marinkovic commented on TAPESTRY-1764: --- my original intend was to create mixins that could use the parameters of the component to decide further actions. a very concrete example is a EnableDisable mixin that would render only the value of a disabled TextField (i know there is a disabled parameter but if enabled it will still render the whole input element; applications with many input fields and high traffic will profit from the reduced page size). therefore i'd be more than satisfied to have an read-only access to the parameter binding from within a mixin. i'm aware that the value of the parameter could be changed by the component but that's ok with me :) because the rendering phases (after/before and MixinAfter) give you a hint on whether the value could have been changed by the component. for me mixins are a great way to add additional (maybe cross-cutting) behavior to a component regarding visual appearance and functionality on the client-side. I do not see mixins as a way to add business logic such as mentioned by kevin i think Validators and Translators are more suitable for this. > provide access to component parameters from within mixins > - > > Key: TAPESTRY-1764 > URL: https://issues.apache.org/jira/browse/TAPESTRY-1764 > Project: Tapestry > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.0.6 >Reporter: Kristian Marinkovic > > A mixin can't access the parameters of a component because the Bindings > property of the InternalComponentResourcesImpl class is private and the > respective interface does not provide a access method. > I was trying to create a mixin that would render only the value of a form > element (without the tags) when it was in a certain state. There also might > be use cases where mixins are used to collect data from the components they > are attached and therefore also needs access to the components parameters. > see threads: > http://www.nabble.com/Antwort%3A--T5--how-to-read-the-value-of-a-component-parameter-within-a-mixin-tf4487995.html > http://www.nabble.com/-T5--how-to-read-the-value-of-a-component-parameter-within-a-mixin-tf4487597.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-2099) typo in contributePartialMarkupRenderer method of TapestryModule: "heatbeat" should be "heartbeat"
typo in contributePartialMarkupRenderer method of TapestryModule: "heatbeat"
should be "heartbeat"
--
Key: TAPESTRY-2099
URL: https://issues.apache.org/jira/browse/TAPESTRY-2099
Project: Tapestry
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.0.10
Reporter: Kristian Marinkovic
Priority: Minor
contributePartialMarkupRenderer contributes the Heartbeat service using the
"heatbeat" id instead of "heartbeat"; errors can occur if other services are
contributed with "heartbeat" contraints.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TAPESTRY-1805) Reverse ordering/exceution of page render phase methods (afterXXX and cleanupRender) incorrect when short-circuiting
[
https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Marinkovic reopened TAPESTRY-1805:
---
please see example in previous comment
> Reverse ordering/exceution of page render phase methods (afterXXX and
> cleanupRender) incorrect when short-circuiting
>
>
> Key: TAPESTRY-1805
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1805
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.0.6
> Environment: Tapestry 5.0.6-SNAPSHOT
> Reporter: Kristian Marinkovic
>Assignee: Howard M. Lewis Ship
>Priority: Critical
>
> ComponentPageElementImpl is responsible for calling the render
> phase methods of the components. It calls the setupRender method
> on the attached Mixins then the components and then the Mixins that
> have a @MixinAfter annotation. If in this phase the setupRender of a
> Mixin returns a boolean value that will be saved into the Event object and
> in case of a "false" the setupRender calls of the subsequent components
> will be aborted.
> During the "inverse" lifecycle the order is simply reversed and the render
> phase method of the Mixin with @MixinAfter annotation is called, then
> the render phase method of the component and then the method of the
> Mixin is called. The problem is now that the "inverse" render phase
> methods are getting called without checking whether the corresponding
> other render phase methods have been executed.
> So in my case the cleanupRender method of the Form component gets
> called although i have short-circuited the beginRender method with my
> Mixin because there is no state available that indicates that the beginRender
> method of the Form component has NOT been executed.
> private void invoke(boolean reverse, ComponentCallback callback)
> {
>
> Iterator i = reverse ?
> InternalUtils.reverseIterator(_components)
> : _components.iterator();
> while (i.hasNext())
> callback.run(i.next());
> A possible solution would be to create a List that contains those
> components whose render phase methods really have been
> executed. This list is then used in the "inverse" lifecycle.
> see also:
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562001.html
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562724.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-2030) creating a service for contribution services to the Environment service
creating a service for contribution services to the Environment service
---
Key: TAPESTRY-2030
URL: https://issues.apache.org/jira/browse/TAPESTRY-2030
Project: Tapestry
Issue Type: New Feature
Affects Versions: 5.0.8
Reporter: Kristian Marinkovic
Priority: Trivial
each time a new (global for one page rendering) service is needed i have to
implement MarkupRendererFilter and contributed it to the MarkupRenderer
service. it would be more convenient to have a service that adds contributed
services directly to the environment.
now:
public void
contributeMarkupRenderer(OrderedConfiguration
configuration,
final MenuManager menuManager, final Environment environment) {
configuration.add("menuManager", new MarkupRendererFilter() {
public void renderMarkup(MarkupWriter writer, MarkupRenderer
renderer) {
environment.push(MenuManager.class, menuManager);
renderer.renderMarkup(writer);
environment.pop(MenuManager.class);
}}, "after:heartbeat");
}
more convenient:
contributeEnvironment(Configuration conf,MenuManager menuManager) {
conf.add(MenuManager.class,menuManager);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-1805) Reverse ordering/exceution of page render phase methods (afterXXX and cleanupRender) incorrect when short-circuiting
[
https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557242#action_12557242
]
Kristian Marinkovic commented on TAPESTRY-1805:
---
my use case: i use (or at least i'd like to:)) mixins is for enable/disable
handling and user rights handling within forms
therefore i have a Editable Mixin that has a boolean parameter that shortcuts
the rendering of a field and only renders/displays the value of the field (btw.
because i can not determine the value of the components value parameter i have
to pass the value to the Editable Mixin as well). furthermore i have a
RoleWarrant Mixin that prevents rendering of page parts the users roles are not
sufficient. both Mixins essentially shortcut the rendering of the components
they are applied to. sometimes they both are applied to the same component
so i shortcut the rendering in Mixin.setupRender because i want to prevent the
rendering. but shortcutting setupRender does not prevent calling
Component.cleanupRender although expected (at least by me). because
Component.setupRender has not been called and therefore has not been able to
initialize its state, exceptions can occur if Component.cleanupRender relies on
the state set in Component.setupRender.
for example this happens if you try to shortcut a Form component because during
the cleanup event it tries to remove a service from the environment it should
have set in the beginRender event. this is a very unsatisfying situation if
many components from different sources are used.
i hope this example helps
> Reverse ordering/exceution of page render phase methods (afterXXX and
> cleanupRender) incorrect when short-circuiting
>
>
> Key: TAPESTRY-1805
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1805
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.0.6
> Environment: Tapestry 5.0.6-SNAPSHOT
>Reporter: Kristian Marinkovic
>Assignee: Howard M. Lewis Ship
>Priority: Critical
>
> ComponentPageElementImpl is responsible for calling the render
> phase methods of the components. It calls the setupRender method
> on the attached Mixins then the components and then the Mixins that
> have a @MixinAfter annotation. If in this phase the setupRender of a
> Mixin returns a boolean value that will be saved into the Event object and
> in case of a "false" the setupRender calls of the subsequent components
> will be aborted.
> During the "inverse" lifecycle the order is simply reversed and the render
> phase method of the Mixin with @MixinAfter annotation is called, then
> the render phase method of the component and then the method of the
> Mixin is called. The problem is now that the "inverse" render phase
> methods are getting called without checking whether the corresponding
> other render phase methods have been executed.
> So in my case the cleanupRender method of the Form component gets
> called although i have short-circuited the beginRender method with my
> Mixin because there is no state available that indicates that the beginRender
> method of the Form component has NOT been executed.
> private void invoke(boolean reverse, ComponentCallback callback)
> {
>
> Iterator i = reverse ?
> InternalUtils.reverseIterator(_components)
> : _components.iterator();
> while (i.hasNext())
> callback.run(i.next());
> A possible solution would be to create a List that contains those
> components whose render phase methods really have been
> executed. This list is then used in the "inverse" lifecycle.
> see also:
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562001.html
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562724.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: [jira] Created: (TAPESTRY-1991) It should be easy to initialize an ASO to null
i see... found the place... but how do you create an ASO then...? you can't just assign it mabe you need something that is more like an object in the environment. The value attribute of the @Environmental annotation can be set to false... so if the object is not present you will get null Hugo Palma <[EMAIL PROTECTED]> 21.12.2007 14:40 Bitte antworten an "Tapestry development" An Tapestry development Kopie Thema Re: [jira] Created: (TAPESTRY-1991) It should be easy to initialize an ASO to null , i think it is possible. In ApplicationStateManagerImpl newAdapter method you'd have to change it's implementation so that the ApplicationStateCreator implementation provided would work like now or if would always return null. Maybe i'm over simplifying things, but it makes sense to me... Kristian Marinkovic wrote: > hi hugo, > > i think what you ask for is not possible because Tapestry 5 generates > proxies to access the ASOs. If you set it to null no proxy will be > available > to check whether there is a new instance in the session. You have the > same problem when you use Hibernate with lazy fields/lists. you always > see the proxies. > > i'm not sure but all i can think of to implement your feature > request/improvemnt > would be to move the ASO logic into the pageAttached events but i > think this > would require some changes... > > g > kris > > > > > > > Hugo Palma <[EMAIL PROTECTED]> > 21.12.2007 14:11 > Bitte antworten an > "Tapestry development" > > > An > Tapestry development > Kopie > > Thema > Re: [jira] Created: (TAPESTRY-1991) It should be easy to initialize an ASO > to null > > > > > > > I know the workarounds, i just don't see the point in any of them. > This should be straight forward, i shouldn't have to use any workaround. > > What's the downside of adding this behaviour to the ASO logic ? > > > Davor Hrg wrote: > >> a boolean value keeping score if the ASO was actually created is >> needed to avoid creating expensive objects on sites with hundreds of >> requests per second. Creating session data for users too early was >> a killer for many apps in all web languages/scripts/frameworks. >> >> instead forcing aso to be null, you can depend on properties inside it >> >> you can chack if aso.user_data!=null >> >> or have a boolean property for /logged in / not >> >> >> Davor Hrg >> >> On Dec 21, 2007 11:12 AM, Hugo Palma <[EMAIL PROTECTED]> wrote: >> >> >>> Yes, the default semantics is that it will only create the ASO instance >>> once you try to access it. >>> Still, it seems to me that many times this semantics doesn't really >>> > make > >>> sense, in the cases where the ASO being null has a meaning. The >>> > simplest > >>> case being for example when you want to keep as an ASO the logged user. >>> >>> I know the docs say that you can keep a boolean value keeping score if >>> the ASO was actually created or not, but to me this seems to go against >>> everything T5 stands for. This kind of thing really should be easy. >>> >>> >>> Davor Hrg wrote: >>> >>> >>>> I haven't checked it in practice, I belived what docs say: >>>> >>>> > http://tapestry.formos.com/nightly/tapestry5/tapestry-core/guide/appstate.html > > >>>> I think the object will not be created if you do not try to access the >>>> > variable. > >>>> Davor Hrg >>>> >>>> On Dec 20, 2007 4:36 PM, Hugo Palma (JIRA) >>>> > wrote: > >>>> >>>>> It should be easy to initialize an ASO to null >>>>> -- >>>>> >>>>> Key: TAPESTRY-1991 >>>>> URL: >>>>> > https://issues.apache.org/jira/browse/TAPESTRY-1991 > >>>>> Project: Tapestry >>>>> Issue Type: Improvement >>>>> Components: Framework >>>>> Affects Versions: 5.0.6 >>>>> Reporter: Hugo Palma >>>>> Priority: Minor >>>>> >>>>> >>>>> By default an ASO is never null. It's automatically created using the >>>>> > ASO class default constructor. > >>>>> It's many times needed to have t
Re: [jira] Created: (TAPESTRY-1991) It should be easy to initialize an ASO to null
hi hugo, i think what you ask for is not possible because Tapestry 5 generates proxies to access the ASOs. If you set it to null no proxy will be available to check whether there is a new instance in the session. You have the same problem when you use Hibernate with lazy fields/lists. you always see the proxies. i'm not sure but all i can think of to implement your feature request/improvemnt would be to move the ASO logic into the pageAttached events but i think this would require some changes... g kris Hugo Palma <[EMAIL PROTECTED]> 21.12.2007 14:11 Bitte antworten an "Tapestry development" An Tapestry development Kopie Thema Re: [jira] Created: (TAPESTRY-1991) It should be easy to initialize an ASO to null I know the workarounds, i just don't see the point in any of them. This should be straight forward, i shouldn't have to use any workaround. What's the downside of adding this behaviour to the ASO logic ? Davor Hrg wrote: > a boolean value keeping score if the ASO was actually created is > needed to avoid creating expensive objects on sites with hundreds of > requests per second. Creating session data for users too early was > a killer for many apps in all web languages/scripts/frameworks. > > instead forcing aso to be null, you can depend on properties inside it > > you can chack if aso.user_data!=null > > or have a boolean property for /logged in / not > > > Davor Hrg > > On Dec 21, 2007 11:12 AM, Hugo Palma <[EMAIL PROTECTED]> wrote: > >> Yes, the default semantics is that it will only create the ASO instance >> once you try to access it. >> Still, it seems to me that many times this semantics doesn't really make >> sense, in the cases where the ASO being null has a meaning. The simplest >> case being for example when you want to keep as an ASO the logged user. >> >> I know the docs say that you can keep a boolean value keeping score if >> the ASO was actually created or not, but to me this seems to go against >> everything T5 stands for. This kind of thing really should be easy. >> >> >> Davor Hrg wrote: >> >>> I haven't checked it in practice, I belived what docs say: >>> http://tapestry.formos.com/nightly/tapestry5/tapestry-core/guide/appstate.html >>> >>> I think the object will not be created if you do not try to access the variable. >>> >>> Davor Hrg >>> >>> On Dec 20, 2007 4:36 PM, Hugo Palma (JIRA) wrote: >>> >>> It should be easy to initialize an ASO to null -- Key: TAPESTRY-1991 URL: https://issues.apache.org/jira/browse/TAPESTRY-1991 Project: Tapestry Issue Type: Improvement Components: Framework Affects Versions: 5.0.6 Reporter: Hugo Palma Priority: Minor By default an ASO is never null. It's automatically created using the ASO class default constructor. It's many times needed to have the null value in an ASO, for example if i want to keep the logged in user in an ASO. Right now we can do this by contributing a new ApplicationStateCreator to the ApplicationStateManager but it seems to me that should be as easy as providing a parameter to the @ApplicationState indicating that you don't want it to be automatically initialized. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
[jira] Updated: (TAPESTRY-1754) Creating a service builder for ValidationDecorator for easier override
[ https://issues.apache.org/jira/browse/TAPESTRY-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Marinkovic updated TAPESTRY-1754: -- Attachment: TapestryModule.java DefaultValidationDecorator extracted as separate service of easier override > Creating a service builder for ValidationDecorator for easier override > -- > > Key: TAPESTRY-1754 > URL: https://issues.apache.org/jira/browse/TAPESTRY-1754 > Project: Tapestry > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.0, 5.0.6 > Reporter: Kristian Marinkovic > Fix For: 5.0.7 > > Attachments: TapestryModule.java > > > A thread-scoped ValidationDecorator service could be easily overridden > through an other decorator service. Tapestry's DefaultValidationDecorator > does not necessarily meet the needs for field decoration. Exchanging the > ValidationDecorator by replacing it in the Environment manually (as described > http://www.nabble.com/How-to-create-my-ValidationDecorator-in-T5--tf4059742.html#a11533833) > when it is globally needed seems cumbersome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-1650) Tracking issue for Ajax support
[ https://issues.apache.org/jira/browse/TAPESTRY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549033 ] Kristian Marinkovic commented on TAPESTRY-1650: --- hi Howard, after doing some experiments with the current AJAX implementation in 5.0.7-SNAPSHOT i have some questions: 1) will it be able to update multiple zones at the same time? (e.g. returning an array of Blocks) 2) wouldn't it be more convenient if we could just set the ids of the components that need to be updated without having to define a zone? as i understand the zone component it is "only" responsible for executing some js effects and for controlling the visibility/display. i think these aspects could be better controlled using Mixins. g, kris ps. thank you for the hard work! > Tracking issue for Ajax support > --- > > Key: TAPESTRY-1650 > URL: https://issues.apache.org/jira/browse/TAPESTRY-1650 > Project: Tapestry > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.0 >Reporter: Howard M. Lewis Ship >Assignee: Howard M. Lewis Ship > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: tap 5 errors in eclipse
do you have the maven2 plugin for eclipse installed? it works fine for me :) g, kris Fernando Padilla <[EMAIL PROTECTED]> 14.11.2007 16:23 Bitte antworten an "Tapestry development" An Tapestry development Kopie Thema tap 5 errors in eclipse So. I have the tap 5 tree imported into my eclipse, but it throws up lots of exceptions saying that it can't find many of the dependencies. I even look at the ClassPath for the project and of course nothing is there. Does someone have the tap 5 tree setup properly under eclipse and I should be checking out what my eclipse is doing wrong? Did Howard's change to IntelliJ confuse the normal eclipse setup? Is it something else? thank you! fernando ps - One thing that I've always wondered, is that there is one large tapestry5 project configured. But how do you set the classpath for the child projects? For our development we don't have a parent project like that, we have each subproject as a separate project.. Is what I said even clear? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSS: Remove Module autoloading
i've also chosen Hivemind and T5 IoC because of autoloading and because of contributions/configurations. finer control is ok for me as long as autoloading is default and as i don't have to add a @SubModule annotation referencing a class of another library introducing more dependencies. maybe T5 IoC should work on top of OSGi. Along with module handling (autoload, access control) we could take advantage of OSGis runtime behaviour. (Eclipse Equinox does support many of the concepts found in T5 IoC like extension-points and extensions aka. configurations and features an autoload bundle) g, kris Ognen Ivanovski <[EMAIL PROTECTED]> 05.11.2007 09:23 Bitte antworten an "Tapestry development" An "Tapestry development" Kopie Thema Re: DISCUSS: Remove Module autoloading On 2007-11-04, at 04:53, Robert Zeigler wrote: > I think autoloading has a lot of merits, and would hate to see it > ripped out. What I /would/ like to see is finer-grained control > over autoloading. For example, a mechanism to specify which > modules should /not/ be autoloaded. +1. Just wanted to write this myself. -- Ognen Ivanovski | [EMAIL PROTECTED] phone +389 -2- 30 64 532 | fax +389 -2- 30 79 495 Netcetera | 1000 Skopje | Macedonia | http://netcetera.com.mk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-1836) Redirect after post causes issues with maintaining client side persistence and forces use of session
[
https://issues.apache.org/jira/browse/TAPESTRY-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535886
]
Kristian Marinkovic commented on TAPESTRY-1836:
---
i think everything you need is to save the serialized data from the From
into an annotated property with @Persist("flash"). The value of the property
will only stay in the session between the two request and will be cleared
afterwards.
the load balancer will have to have sticky session enabled so the second
request (redirect) reaches the same T5 instance.
g,
kris
> Redirect after post causes issues with maintaining client side persistence
> and forces use of session
>
>
> Key: TAPESTRY-1836
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1836
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.0.5
>Reporter: kron bars
>
> We have a lot of pages that serialize objects into the form (gzip + base 64).
> This is necessary because we want to absolutely avoid using the session
> (clustering concerns and multiple-browsers with same session concerns). In
> T5, a form post results in a redirect. So if serialized state is present in
> the form, the redirect will necessarily cause that to be lost (the URL with
> its 256 character limitation is not an option to pass the state through).
> Thus we are forced to hold the state in session. This leads to major problems
> when the user has multiple browsers open into the same session (which they
> always do given the nature of our application).
> An option is required to disable the redirect after form post.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-1805) Reverse ordering/exceution of page render phase methods (afterXXX and cleanupRender) incorrect when short-circuiting
[
https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532602
]
Kristian Marinkovic commented on TAPESTRY-1805:
---
https://issues.apache.org/jira/browse/TAPESTRY-1662 is quite similar :)
do you know how howard perceives this bugs? do you think there we'll be a
solution soon? I use Mixins a lot
for enable/disable handling and for short-circuiting of render phases (that
makes the use of if components almost unnecessary) and page
decoration/enhancement (HTML, JS). for me it is important to have them
integrate into the rendering phases correctly. a great way to achieve
separation of concerns.
summary of how i think t5 event handling should work:
as you mentioned in your bug and as it is documented a short-circuit will omit
the inner render phase methods.
if a component has a mixin attached the component render phase methods become
the inner render phase methods of my mixin. therefore a mixin short-circuit
will omit the components render phase methods.. even the inverse one ... and
the other way round if you have MixinAfter :)
g,
kris
> Reverse ordering/exceution of page render phase methods (afterXXX and
> cleanupRender) incorrect when short-circuiting
>
>
> Key: TAPESTRY-1805
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1805
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.0.6
> Environment: Tapestry 5.0.6-SNAPSHOT
>Reporter: Kristian Marinkovic
>Priority: Critical
>
> ComponentPageElementImpl is responsible for calling the render
> phase methods of the components. It calls the setupRender method
> on the attached Mixins then the components and then the Mixins that
> have a @MixinAfter annotation. If in this phase the setupRender of a
> Mixin returns a boolean value that will be saved into the Event object and
> in case of a "false" the setupRender calls of the subsequent components
> will be aborted.
> During the "inverse" lifecycle the order is simply reversed and the render
> phase method of the Mixin with @MixinAfter annotation is called, then
> the render phase method of the component and then the method of the
> Mixin is called. The problem is now that the "inverse" render phase
> methods are getting called without checking whether the corresponding
> other render phase methods have been executed.
> So in my case the cleanupRender method of the Form component gets
> called although i have short-circuited the beginRender method with my
> Mixin because there is no state available that indicates that the beginRender
> method of the Form component has NOT been executed.
> private void invoke(boolean reverse, ComponentCallback callback)
> {
>
> Iterator i = reverse ?
> InternalUtils.reverseIterator(_components)
> : _components.iterator();
> while (i.hasNext())
> callback.run(i.next());
> A possible solution would be to create a List that contains those
> components whose render phase methods really have been
> executed. This list is then used in the "inverse" lifecycle.
> see also:
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562001.html
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562724.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-1805) Reverse ordering/exceution of page render phase methods (afterXXX and cleanupRender) incorrect when short-circuiting
[
https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532584
]
Kristian Marinkovic commented on TAPESTRY-1805:
---
hi nick,
the point is why should a inverse render phase method of a nested component be
called if the component has not be rendered or the corresponding render phase
method has not been called.
so... why call cleanupRender if setupRender has not been called? :) if you
return false on beginRender the beforeRenderRemplate won't be called either.
i don't think components should be aware of short-circuiting... makes it just
harder for developers
g,
kris
p.s.
the quick solution for me was to make the cleanupRender method of the Tapestry
Form component public and to create an own Form component by extending Tapestry
Form. This Form component overrides cleanupRender after it checked the
Environment with peek
> Reverse ordering/exceution of page render phase methods (afterXXX and
> cleanupRender) incorrect when short-circuiting
>
>
> Key: TAPESTRY-1805
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1805
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.0.6
> Environment: Tapestry 5.0.6-SNAPSHOT
>Reporter: Kristian Marinkovic
>Priority: Critical
>
> ComponentPageElementImpl is responsible for calling the render
> phase methods of the components. It calls the setupRender method
> on the attached Mixins then the components and then the Mixins that
> have a @MixinAfter annotation. If in this phase the setupRender of a
> Mixin returns a boolean value that will be saved into the Event object and
> in case of a "false" the setupRender calls of the subsequent components
> will be aborted.
> During the "inverse" lifecycle the order is simply reversed and the render
> phase method of the Mixin with @MixinAfter annotation is called, then
> the render phase method of the component and then the method of the
> Mixin is called. The problem is now that the "inverse" render phase
> methods are getting called without checking whether the corresponding
> other render phase methods have been executed.
> So in my case the cleanupRender method of the Form component gets
> called although i have short-circuited the beginRender method with my
> Mixin because there is no state available that indicates that the beginRender
> method of the Form component has NOT been executed.
> private void invoke(boolean reverse, ComponentCallback callback)
> {
>
> Iterator i = reverse ?
> InternalUtils.reverseIterator(_components)
> : _components.iterator();
> while (i.hasNext())
> callback.run(i.next());
> A possible solution would be to create a List that contains those
> components whose render phase methods really have been
> executed. This list is then used in the "inverse" lifecycle.
> see also:
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562001.html
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562724.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-1805) Reverse ordering/exceution of page render phase methods (afterXXX and cleanupRender) incorrect when short-circuiting
Reverse ordering/exceution of page render phase methods (afterXXX and
cleanupRender) incorrect when short-circuiting
Key: TAPESTRY-1805
URL: https://issues.apache.org/jira/browse/TAPESTRY-1805
Project: Tapestry
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.0.6
Environment: Tapestry 5.0.6-SNAPSHOT
Reporter: Kristian Marinkovic
ComponentPageElementImpl is responsible for calling the render
phase methods of the components. It calls the setupRender method
on the attached Mixins then the components and then the Mixins that
have a @MixinAfter annotation. If in this phase the setupRender of a
Mixin returns a boolean value that will be saved into the Event object and
in case of a "false" the setupRender calls of the subsequent components
will be aborted.
During the "inverse" lifecycle the order is simply reversed and the render
phase method of the Mixin with @MixinAfter annotation is called, then
the render phase method of the component and then the method of the
Mixin is called. The problem is now that the "inverse" render phase
methods are getting called without checking whether the corresponding
other render phase methods have been executed.
So in my case the cleanupRender method of the Form component gets
called although i have short-circuited the beginRender method with my
Mixin because there is no state available that indicates that the beginRender
method of the Form component has NOT been executed.
private void invoke(boolean reverse, ComponentCallback callback)
{
Iterator i = reverse ?
InternalUtils.reverseIterator(_components)
: _components.iterator();
while (i.hasNext())
callback.run(i.next());
A possible solution would be to create a List that contains those
components whose render phase methods really have been
executed. This list is then used in the "inverse" lifecycle.
see also:
http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562001.html
http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562724.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TAPESTRY-1805) Reverse ordering/exceution of page render phase methods (afterXXX and cleanupRender) incorrect when short-circuiting
[
https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Marinkovic updated TAPESTRY-1805:
--
Priority: Critical (was: Major)
> Reverse ordering/exceution of page render phase methods (afterXXX and
> cleanupRender) incorrect when short-circuiting
>
>
> Key: TAPESTRY-1805
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1805
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.0.6
> Environment: Tapestry 5.0.6-SNAPSHOT
> Reporter: Kristian Marinkovic
>Priority: Critical
>
> ComponentPageElementImpl is responsible for calling the render
> phase methods of the components. It calls the setupRender method
> on the attached Mixins then the components and then the Mixins that
> have a @MixinAfter annotation. If in this phase the setupRender of a
> Mixin returns a boolean value that will be saved into the Event object and
> in case of a "false" the setupRender calls of the subsequent components
> will be aborted.
> During the "inverse" lifecycle the order is simply reversed and the render
> phase method of the Mixin with @MixinAfter annotation is called, then
> the render phase method of the component and then the method of the
> Mixin is called. The problem is now that the "inverse" render phase
> methods are getting called without checking whether the corresponding
> other render phase methods have been executed.
> So in my case the cleanupRender method of the Form component gets
> called although i have short-circuited the beginRender method with my
> Mixin because there is no state available that indicates that the beginRender
> method of the Form component has NOT been executed.
> private void invoke(boolean reverse, ComponentCallback callback)
> {
>
> Iterator i = reverse ?
> InternalUtils.reverseIterator(_components)
> : _components.iterator();
> while (i.hasNext())
> callback.run(i.next());
> A possible solution would be to create a List that contains those
> components whose render phase methods really have been
> executed. This list is then used in the "inverse" lifecycle.
> see also:
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562001.html
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562724.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE : RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ???
just my 2 cent: i'd vote for a solution that creates a javascript abstraction layer. not a single tapestry component should generate the javascript code itself but delegate it to this layer. The only information this layer would need is the generated id of the component and some meta information. this unique approach would give Tapestry 5 a competitive advantage over other web frameworks as it could support multiple javascript libraries. because the importance of client side scripting rises (or is already high) and the complexity and size of generated pages rises too the choice for the *right* javascript library may be crucial for a responsive ui. from my experience using dojo 0.4.2 for big uis can degrade the user experience and responisvenss due to long loading times (compared to other libraries), and awkward implementations within the library (not to mention the usage of the dojo api compared to jquery's api) i also think such an abstraction layer would allow optimizations of the client side javascript code. for example you could apply event delegation for certain parts of the generated page (actionlinks within a loop, or table). furthermore i hope several 3rd party components will emerge using this abstraction layer to deliver rich javascript components :) Tapestry (Howard) emphasizes separation of concerns therefore a javascript abstraction layer - from my point of view - is the way go .. :) but i don't know what default library to choose. i'd probably go for prototype... it offers the necessary api for event handling, ajax, using css selectors for retrieving dom nodes... and is small .. although i haven't looked at dojo 0.9 recently. ... and jquerys plugin mechanism has more appeal than dojos require g, kris Julien HENRY <[EMAIL PROTECTED]> 03.10.2007 14:02 Bitte antworten an "Tapestry development" An Tapestry development Kopie Thema RE : RE: Prototype vs. JQuery vs. Dojo 0.9 vs. ??? @Ben: Do you think about something like GWT? I mean programming JavaScript in Java. Components (especially AJAX ones) will certainly use various existing JavaScript libraries. I think the main issue is "what about T5 core components?". Should they use a specific library (without preventing additional components for using their own)? Don't know what could be the best solution... sorry. --- Ben Sommerville <[EMAIL PROTECTED]> a écrit : > I've been mulling on this topic for a while since > I'm working > (intermittently) > on a project that uses JQuery & Tap5. > > I would love it if Tapestry core was not coupled to > any particular > javascript > library & could also be used without any javascript > at all. > > Obviously to do this we'd need to introduce an > abstraction/indirection > layer > for the parts of tapestry that may use javascript. > The two approaches I > see > are: > a) Define a java api for invoking/using/generating > javascript that > Tapestry >core uses, then create modules for each > javascript library > (as Joost suggested) > b) Define an javascript api that Tapestry invokes > then create > implementations > of that for various javascript libraries >(as Andreas suggested) > > My preference is the first approach for a couple of > reasons: > - it forces a strict separation. Tapestry core > never directly constructs > javascript so there is no chance it will use > functions/etc from a > particular > library > - it means that there can be a lot more freedom on > how the javascript is > written. e.g. field validations could be > accumulated & written out as a > JSON data type, added directly to elements via > css/custom attributes or > accumulated via function calls (as is done > presently). > - tapestry core makes no assumptions about the > client side environment. I > > can see this being a benefit when dealing with other > platforms such as > mobile phones. > > On the downside it may be harder to construct a good > java api that covers > all the possibilities. However that is no reason not > to try! :) > > > cheers > Ben > > > > -Original Message- > > From: Andreas Andreou [mailto:[EMAIL PROTECTED] > On Behalf Of andyhot > > Sent: Wednesday, 3 October 2007 1:58 PM > > To: Tapestry development > > Subject: Re: Prototype vs. JQuery vs. Dojo 0.9 vs. > ??? > > > > I think you're misunderstanding my intentions :) > > > > Here are the facts the way i see them: > > - Tapestry needs some js functions for its own > use, hence tapestry.js > > - I do NOT want to force users (not even myself) > to go through > > tapestry.js - they should be able to > > use the library they want to > > - I do NOT want to force users to have to load > another library simply > > because tapestry.js needs it > > > > And here's where i'd be heading at: > > - Plan js usage in such a way that alternatives to > > > tapestry.js (such as > > tapestry-yui.js or tapestry-jquery.js, > > or even tapestry-donothing.js) are easy to write > and even > > eas
[jira] Commented: (TAPESTRY-1650) Tracking issue for Ajax support
[ https://issues.apache.org/jira/browse/TAPESTRY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530057 ] Kristian Marinkovic commented on TAPESTRY-1650: --- i think a good idea would be to create a separate project for the javascript integration > Tracking issue for Ajax support > --- > > Key: TAPESTRY-1650 > URL: https://issues.apache.org/jira/browse/TAPESTRY-1650 > Project: Tapestry > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.0 >Reporter: Howard M. Lewis Ship > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-1764) provide access to component parameters from within mixins
provide access to component parameters from within mixins - Key: TAPESTRY-1764 URL: https://issues.apache.org/jira/browse/TAPESTRY-1764 Project: Tapestry Issue Type: Improvement Components: tapestry-core Affects Versions: 5.0.6 Reporter: Kristian Marinkovic A mixin can't access the parameters of a component because the Bindings property of the InternalComponentResourcesImpl class is private and the respective interface does not provide a access method. I was trying to create a mixin that would render only the value of a form element (without the tags) when it was in a certain state. There also might be use cases where mixins are used to collect data from the components they are attached and therefore also needs access to the components parameters. see threads: http://www.nabble.com/Antwort%3A--T5--how-to-read-the-value-of-a-component-parameter-within-a-mixin-tf4487995.html http://www.nabble.com/-T5--how-to-read-the-value-of-a-component-parameter-within-a-mixin-tf4487597.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-1754) Creating a service builder for ValidationDecorator for easier override
Creating a service builder for ValidationDecorator for easier override -- Key: TAPESTRY-1754 URL: https://issues.apache.org/jira/browse/TAPESTRY-1754 Project: Tapestry Issue Type: Improvement Components: tapestry-core Affects Versions: 5.0, 5.0.6 Reporter: Kristian Marinkovic Fix For: 5.0.6 A thread-scoped ValidationDecorator service could be easily overridden through an other decorator service. Tapestry's DefaultValidationDecorator does not necessarily meet the needs for field decoration. Exchanging the ValidationDecorator by replacing it in the Environment manually (as described http://www.nabble.com/How-to-create-my-ValidationDecorator-in-T5--tf4059742.html#a11533833) when it is globally needed seems cumbersome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-1650) Tracking issue for Ajax support
[ https://issues.apache.org/jira/browse/TAPESTRY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514783 ] Kristian Marinkovic commented on TAPESTRY-1650: --- hi howard, i want to use this tracking issue on ajax to share some of my thoughts on tapestry 5 ajax (javascript) integration. I hope you find it useful and other tapestry enthusiasts will comment on it : 1. T5 should not generate javascript that is specific to a certain javascript library. instead T5 should generate a javascript array (or json object) that is interpreted by a tapestry script that calls the specific javascript library function calls. IMHO the integration of dojo into T4.1 was so tight that it was almost impossible to switch without rewriting the components (jesse don't get me wrong, you did a great job; i use EventListener all the time :)) For example: ActionLink should trigger an ajax event. therefore it gets a mixin (thats what i did:)) or (EventListener) annotation or whatever associated that ensures that the component contains a unique id and stores it in a map. at the end of the page render phase a javascript array with the ids of the annotated components gets rendered. on page load (onLoad) a T5 script interprets the ids and adds the necessary event listener (and everything else) using the javascript library specific function calls. Adoption of another javascript libraries would just require a small change in a javascript file. 2. T5 should use javascript event delegation wherever possible. by default all events are registered onto the body node. if an event bubbles up a T5 script gets started that first starts to find out which node caused the event. it does so by reading the node's id and then matching it with the ids in the previously generated javascript array. on a miss the parent node is checked ... and so on up to the body node. if an adequate entry is found (id and event type) the registered function/ajax call is called. i experienced situations in our T4 applications where an uncontrolled use of event listeners (think of a calendar component placed multiple times on a page where every day node has an event listener attached :)) or really big lists of input fields with event listeners attached ... can cause considerable loss of performance on the client side. event delegation would minimize the javascript complexity on the client side to a minimum resulting in better performance (note: firefox will display the page and pause any user interaction till every event listener is attached, ie6/7 will show nothing till every event listener is attached) 2.1. possibility to define an alternative/additional event delegate (maybe with a separate annotation ... or just a parameter). so it should be possible to have several javascript event delegates on a page for event grouping. i think of a list of links generated in a loop whose events get processed by an enclosing element. 3. integrate all the features of @EventListener from T4 : form, sync, async, json support, component update :) i hope i could express myself in a way everyone understands... please don't forget: english is not my native language :) > Tracking issue for Ajax support > --- > > Key: TAPESTRY-1650 > URL: https://issues.apache.org/jira/browse/TAPESTRY-1650 > Project: Tapestry > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.0 >Reporter: Howard M. Lewis Ship > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-1562) PageLoaderProcessor handles embeddedComponentIds case-sensitive -> should be case-insensitive
PageLoaderProcessor handles embeddedComponentIds case-sensitive -> should be
case-insensitive
-
Key: TAPESTRY-1562
URL: https://issues.apache.org/jira/browse/TAPESTRY-1562
Project: Tapestry
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.0.5
Reporter: Kristian Marinkovic
Priority: Minor
The PageLoaderProcessor does not handle embedded componentIds as case
insensitive.
Therefore logging the error message "embeddedComponentsNotInTemplate".
(Please see commented source snippet)
private void loadTemplateForComponent(ComponentPageElement loadingElement) {
...
// TODO: should make embedded ids eg. lowercase
Set embeddedIds =
CollectionFactory.newSet(_loadingComponentModel
.getEmbeddedComponentIds());
_idAllocator.clear();
for (String id : template.getComponentIds())
{
_idAllocator.allocateId(id);
// TODO: should make id lowercase before remove
embeddedIds.remove(id);
}
// TODO: because the set is case-sensitive this messages gets logged if
the component
// id is written in different cases in template and java class
if (!embeddedIds.isEmpty())
log.error(ServicesMessages.embeddedComponentsNotInTemplate(
embeddedIds,
componentClassName));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-1434) Not possible to create a service without an interface via service builders
Not possible to create a service without an interface via service builders --- Key: TAPESTRY-1434 URL: https://issues.apache.org/jira/browse/TAPESTRY-1434 Project: Tapestry Issue Type: Bug Components: tapestry-ioc Affects Versions: 5.0.4 Reporter: Kristian Marinkovic It is possible using ServiceBinder but not via the service builders -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TAPESTRY-1241) @EventListener produces multiple events
[ https://issues.apache.org/jira/browse/TAPESTRY-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Marinkovic reopened TAPESTRY-1241: --- hi jesse, i think i know why you can't reproduce the bug. Iis it possible you have org.apache.tapestry.disable-caching=true set? Caching must be enabled to reproduce this bug :) greetings, kris > @EventListener produces multiple events > --- > > Key: TAPESTRY-1241 > URL: https://issues.apache.org/jira/browse/TAPESTRY-1241 > Project: Tapestry > Issue Type: Bug > Components: XHR/dhtml/Ajax >Affects Versions: 4.1.1 > Environment: Tapestry 4.1.1 and 4.1.2-20070121 > Reporter: Kristian Marinkovic > Assigned To: Jesse Kuhnert >Priority: Blocker > Fix For: 4.1.2 > > Attachments: EventListener.zip > > > Adding an EventListener to the parent HTML element seems to add additional > @EventListener to the Tapestry components on every Javascript event. This > results > in the generation of multiple "tapestry.event(hash)=function..." statements > although > only one is correct. This gets apparent when the page is submitted and > re-rendered > again. > i added a maven2 example project to reproduce the bug. > please follow these steps: > 1) click on "submit" > 2) click on the second and forth list element and watch the console (should > print list-0 and list-2... the target component of the javascript event) > 3) click again on "submit" (you might change the value if you want) > 4) click again on the second list element and watch the console -> list-0 > will appear twice > 5) take a look at the generated page to see the multiple tapestry.event > statements -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-1241) @EventListener produces multiple events
[
https://issues.apache.org/jira/browse/TAPESTRY-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472228
]
Kristian Marinkovic commented on TAPESTRY-1241:
---
hi jesse,
i just did a clean checkout and built tapestry 4.1.2-SNAPSHOT on my local
machine.
After starting up tomcat i could reproduce the bug (btw. some test fail :)).
The javascript code of the page looks like this when first started:
dojo.addOnLoad(function(e) {
dojo.require("tapestry.form");tapestry.form.registerForm("Form");
tapestry.form.focusField('iteration');
tapestry.cleanConnect(dojo.byId("ul"), "onclick", "event1675372791");
tapestry.event1675372791=function(e){
var content={beventname:"onclick"};
tapestry.event.buildEventProperties(e, content);
if (!content["beventtarget.id"]) {
content["beventtarget.id"]="ul";
}
tapestry.bind("/event/app?component=ul&page=Home&service=directevent", content);
};
dojo.event.connect(dojo.byId("ul"), "onclick", tapestry,
"event1675372791");});
When i then click on the first item it outputs "list" correctly into my
console.
Reloading the page then with the submit link returns following javascript code,
that causes the
multiple events:
dojo.addOnLoad(function(e) {
dojo.require("tapestry.form");tapestry.form.registerForm("Form");
tapestry.form.focusField('iteration');
tapestry.cleanConnect(dojo.byId("ul"), "onclick", "event1675372791");
tapestry.event1675372791=function(e){
var content={beventname:"onclick"};
tapestry.event.buildEventProperties(e, content);
if (!content["beventtarget.id"]) {
content["beventtarget.id"]="ul";
}
tapestry.bind("/event/app?component=ul&page=Home&service=directevent", content);
};
dojo.event.connect(dojo.byId("ul"), "onclick", tapestry,
"event1675372791");
tapestry.cleanConnect(dojo.byId("list"), "onclick", "event526584677");
tapestry.event526584677=function(e){
var content={beventname:"onclick"};
tapestry.event.buildEventProperties(e, content);
if (!content["beventtarget.id"])
content["beventtarget.id"]="list";
tapestry.bind("/event/app?component=ul&page=Home&service=directevent", content);
};
dojo.event.connect(dojo.byId("list"), "onclick", tapestry,
"event526584677");});
For any event that was triggered an additional javascript block will be
generated on any new
page reload via the submit link. i suspect there is a place anywhere where
there is some sort
of state information where it shouldn't be. Or maybe the events are
missinterpreted as additional
@EventListener annotations. i must admit i was not able to find this specific
place :)
i hope this helps to reproduce the bug
ps. sorry for being so annoying :)
> @EventListener produces multiple events
> ---
>
> Key: TAPESTRY-1241
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1241
> Project: Tapestry
> Issue Type: Bug
> Components: XHR/dhtml/Ajax
>Affects Versions: 4.1.1
> Environment: Tapestry 4.1.1 and 4.1.2-20070121
>Reporter: Kristian Marinkovic
> Assigned To: Jesse Kuhnert
>Priority: Blocker
> Fix For: 4.1.2
>
> Attachments: EventListener.zip
>
>
> Adding an EventListener to the parent HTML element seems to add additional
> @EventListener to the Tapestry components on every Javascript event. This
> results
> in the generation of multiple "tapestry.event(hash)=function..." statements
> although
> only one is correct. This gets apparent when the page is submitted and
> re-rendered
> again.
> i added a maven2 example project to reproduce the bug.
> please follow these steps:
> 1) click on "submit"
> 2) click on the second and forth list element and watch the console (should
> print list-0 and list-2... the target component of the javascript event)
> 3) click again on "submit" (you might change the value if you want)
> 4) click again on the second list element and watch the console -> list-0
> will appear twice
> 5) take a look at the generated page to see the multiple tapestry.event
> statements
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TAPESTRY-1245) Alter LinkSubmit to output javascript in onclick (instead of in href)
[ https://issues.apache.org/jira/browse/TAPESTRY-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471233 ] Kristian Marinkovic commented on TAPESTRY-1245: --- +1 for adding events via dojo.connect > Alter LinkSubmit to output javascript in onclick (instead of in href) > - > > Key: TAPESTRY-1245 > URL: https://issues.apache.org/jira/browse/TAPESTRY-1245 > Project: Tapestry > Issue Type: Improvement > Components: Core >Affects Versions: 4.1.1 >Reporter: Andreas Andreou > Fix For: 4.1.2 > > > i'd prefer not to use the href attribute for this. It's semantically > incorrect, the status-bar gets ugly, phone browsers dislike it, e.t.c. > Even better, don't output any javascript inside the link tag - have the html > clean and hava dojo wire up the onclick event -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TAPESTRY-1241) @EventListener produces multiple events
[ https://issues.apache.org/jira/browse/TAPESTRY-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Marinkovic updated TAPESTRY-1241: -- Component/s: XHR/dhtml/Ajax > @EventListener produces multiple events > --- > > Key: TAPESTRY-1241 > URL: https://issues.apache.org/jira/browse/TAPESTRY-1241 > Project: Tapestry > Issue Type: Bug > Components: XHR/dhtml/Ajax >Affects Versions: 4.1.1 > Environment: Tapestry 4.1.1 and 4.1.2-20070121 >Reporter: Kristian Marinkovic >Priority: Blocker > Attachments: EventListener.zip > > > Adding an EventListener to the parent HTML element seems to add additional > @EventListener to the Tapestry components on every Javascript event. This > results > in the generation of multiple "tapestry.event(hash)=function..." statements > although > only one is correct. This gets apparent when the page is submitted and > re-rendered > again. > i added a maven2 example project to reproduce the bug. > please follow these steps: > 1) click on "submit" > 2) click on the second and forth list element and watch the console (should > print list-0 and list-2... the target component of the javascript event) > 3) click again on "submit" (you might change the value if you want) > 4) click again on the second list element and watch the console -> list-0 > will appear twice > 5) take a look at the generated page to see the multiple tapestry.event > statements -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TAPESTRY-1241) @EventListener produces multiple events
[ https://issues.apache.org/jira/browse/TAPESTRY-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Marinkovic updated TAPESTRY-1241: -- Attachment: EventListener.zip maven2 project to reproduce the bug > @EventListener produces multiple events > --- > > Key: TAPESTRY-1241 > URL: https://issues.apache.org/jira/browse/TAPESTRY-1241 > Project: Tapestry > Issue Type: Bug >Affects Versions: 4.1.1 > Environment: Tapestry 4.1.1 and 4.1.2-20070121 > Reporter: Kristian Marinkovic >Priority: Blocker > Attachments: EventListener.zip > > > Adding an EventListener to the parent HTML element seems to add additional > @EventListener to the Tapestry components on every Javascript event. This > results > in the generation of multiple "tapestry.event(hash)=function..." statements > although > only one is correct. This gets apparent when the page is submitted and > re-rendered > again. > i added a maven2 example project to reproduce the bug. > please follow these steps: > 1) click on "submit" > 2) click on the second and forth list element and watch the console (should > print list-0 and list-2... the target component of the javascript event) > 3) click again on "submit" (you might change the value if you want) > 4) click again on the second list element and watch the console -> list-0 > will appear twice > 5) take a look at the generated page to see the multiple tapestry.event > statements -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-1241) @EventListener produces multiple events
@EventListener produces multiple events --- Key: TAPESTRY-1241 URL: https://issues.apache.org/jira/browse/TAPESTRY-1241 Project: Tapestry Issue Type: Bug Affects Versions: 4.1.1 Environment: Tapestry 4.1.1 and 4.1.2-20070121 Reporter: Kristian Marinkovic Priority: Blocker Adding an EventListener to the parent HTML element seems to add additional @EventListener to the Tapestry components on every Javascript event. This results in the generation of multiple "tapestry.event(hash)=function..." statements although only one is correct. This gets apparent when the page is submitted and re-rendered again. i added a maven2 example project to reproduce the bug. please follow these steps: 1) click on "submit" 2) click on the second and forth list element and watch the console (should print list-0 and list-2... the target component of the javascript event) 3) click again on "submit" (you might change the value if you want) 4) click again on the second list element and watch the console -> list-0 will appear twice 5) take a look at the generated page to see the multiple tapestry.event statements -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TAPESTRY-1240) LinkSubmit with parameters causes exception although it has validators attached
LinkSubmit with parameters causes exception although it has validators attached
---
Key: TAPESTRY-1240
URL: https://issues.apache.org/jira/browse/TAPESTRY-1240
Project: Tapestry
Issue Type: Bug
Components: Framework
Affects Versions: 4.1.1, 4.1, 4.1.2
Environment: last test was with Tapestry 4.1.2-20070121
Reporter: Kristian Marinkovic
A LinkSubmit component causes an exception if the bound listener requires one
or more parameters and
the values of the parameters binding are null. This behavior is correct as long
as the bound parameters
don't come from a TextField with a "required" validator.
Looking at the code below i would have expected that when the page is
submitted, the TextField component
gets validated before the LinkSubmit. If so Tapestry would report the
validation error and not the exception.
.page file
.java file
public void readGPList(String txtSearchField) {}
g,
kris
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
