Re: [jira] [Comment Edited] (TAP5-2332) Optimize String concatenation performance
If every commit HLS has done would get such scrutiny, nothing would ever get done... Just sayin. > On May 22, 2014, at 1:17 PM, "Thiago H de Paula Figueiredo" > wrote: > >> On Thu, 22 May 2014 12:41:31 -0300, Jochen Kemnade >> wrote: >> >> Am 22.05.2014 17:11, schrieb Robert Zeigler: >>> I can see optionmodelimpl being a hotspot if it is being rendered on a page >>> with many selects, or selects with many options since methods within will >>> be invoked once per option. >> >> But rendering won't call the toString function. I guess, the OptionModelImpl >> change was just made for "while we're at it" reasons. > > That's the whole point why this method shouldn't be changed. It's only using > for debugging, so changing it won't make Tapestry run any faster. > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.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] Drop support for Java 5 in Tapestry 5.4
Lenny Primak: +1 (non-binding) A huge +1 for 5.3.8 release that supports Java 8. > On May 16, 2014, at 3:54 PM, Bob Harner wrote: > > Bob Harner: +1 (non-binding) > > (As an aside, it's been over a year since our last 5.3.x release. It > might be good to put out a 5.3.8 release soon, which will remain Java > 5 compatible, of course.) > > On Thu, May 15, 2014 at 9:14 AM, 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 > > - > 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
Tapestry 5.3.x should be Java 8 compatible
I created a separate JIRA for this: https://issues.apache.org/jira/browse/TAP5-2321 Thank you - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Tapestry 5.4 and java8
We should make a 5.3.x release that's compatible with java 8 ASAP. > On Mar 20, 2014, at 4:15 PM, Kalle Korhonen > wrote: > > Sure, no problem. We still need it released but that might have to wait > till 5.4 GA release. Easy enough for those who need it to build it > themselves though. > > Kalle > > > On Thu, Mar 20, 2014 at 1:03 PM, Joachim Van der Auwera wrote: > >> THanks Kalle for doing this. >> >> Kind regards, >> Joachim >> >> >>> On 03/18/2014 08:32 PM, Joachim Van der Auwera wrote: >>> >>> Java8 is now officially available. >>> ASM 5.0 has also been released (see http://forge.ow2.org/forum/ >>> forum.php?forum_id=2302) >>> >>> Could the ASM5 be integrated in Tapestry 5.4 and a new beta release >>> built? This way Tapestry could be used in Java8. >>> >>> Kind regards, >>> Joachim >>> >>> - >>> 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: Tapestry 5.4 and java8
Same applies to Tapestry 5.3.x branch. On Mar 18, 2014, at 3:32 PM, Joachim Van der Auwera wrote: > Java8 is now officially available. > ASM 5.0 has also been released (see > http://forge.ow2.org/forum/forum.php?forum_id=2302) > > Could the ASM5 be integrated in Tapestry 5.4 and a new beta release built? > This way Tapestry could be used in Java8. > > Kind regards, > Joachim > > - > 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: Tapestry 5.3.x and Java 8
Voted. Also added a comment to do the same for 5.3.x On Feb 2, 2014, at 11:29 AM, Bob Harner wrote: > Lenny, you add your name to the "demand" list by voting on the issue at > https://issues.apache.org/jira/browse/TAP5-2214 > > I've been playing with JDK 8 some myself and see a lot in there that > Tapestry could benefit from. At some point (but not soon) we may need a JDK > 8-specific branch to introduce API changes for lambda expressions, default > methods, and other cool new toys. > On Feb 1, 2014 12:35 PM, "Lenny Primak" wrote: > >> Thanks Bob for the explanation. >> You can put my name of the list of 'demand' for this. >> I am pretty sure that when JDK8 starts breaking T5.3, there will be a lot >> more 'demanders' >> >> >> On Feb 1, 2014, at 11:16 AM, Bob Harner wrote: >> >>> Lenny, >>> >>> As for whether ASM will be upgraded in the next version of 5.3, I >>> don't see why not, if there is any demand for it. All the developer >>> focus has been on 5.4, of course, so currently there doesn't seem to >>> be a need for any 5.3.8 release. As always, that can change. >>> >>> As I understand it, ASM is "baked in" with a modified package name so >>> that there isn't a risk of class conflicts with any other occurrences >>> of ASM in users' applications and libraries such as Hibernate. Read >>> the last sentence at http://asm.ow2.org/doc/faq.html >>> >>> On Fri, Jan 31, 2014 at 5:42 PM, Lenny Primak >> wrote: >>>> I am trying to find out about 5.3 specifically, not 5.4. >>>> I am sure that 5.4 is going to be upgraded to ASM that's compatible >> with Java 8 at some point, >>>> but our projects are using 5.3, and we don't plan to upgrade to 5.4 for >> various reasons. >>>> So, if there are no plans for upgrading 5.3 to the new ASM, we need to >> think about >>>> alternate plans ahead of time. >>>> >>>> Also, is there a particular reason why ASM is 'baked in' to plastic, as >> opposed >>>> to just having a separate maven / gradle dependency on it? >>>> Seems to be much easier to upgrade if it's a regular dependency rather >> than jarjar'd. >>>> >>>> >>>> On Jan 31, 2014, at 2:04 PM, Joachim Van der Auwera wrote: >>>> >>>>> I am currently using Tapestry 5.4 on Java8 by applying the patch given >> in https://issues.apache.org/jira/browse/TAP5-2214. >>>>> I have not (yet) found other issues when using Java8. >>>>> >>>>> Personally, I would like to see this patch applied, but I understand >> that including a non-release version of ASM is not ideal. >>>>> >>>>> Kind regards, >>>>> Joachim >>>>> >>>>> On 01/31/2014 07:44 PM, Lenny Primak wrote: >>>>>> Is there a plan to update 5.3.x when Java 8 comes out? >>>>>> Is it just the matter of the version of ASM that is used or is there >> something >>>>>> else that precludes 5.3.x to run on Java 8? >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> - >>>>>> 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 >>> >> >> >> - >> 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: Tapestry 5.3.x and Java 8
Thanks Bob for the explanation. You can put my name of the list of 'demand' for this. I am pretty sure that when JDK8 starts breaking T5.3, there will be a lot more 'demanders' On Feb 1, 2014, at 11:16 AM, Bob Harner wrote: > Lenny, > > As for whether ASM will be upgraded in the next version of 5.3, I > don't see why not, if there is any demand for it. All the developer > focus has been on 5.4, of course, so currently there doesn't seem to > be a need for any 5.3.8 release. As always, that can change. > > As I understand it, ASM is "baked in" with a modified package name so > that there isn't a risk of class conflicts with any other occurrences > of ASM in users' applications and libraries such as Hibernate. Read > the last sentence at http://asm.ow2.org/doc/faq.html > > On Fri, Jan 31, 2014 at 5:42 PM, Lenny Primak wrote: >> I am trying to find out about 5.3 specifically, not 5.4. >> I am sure that 5.4 is going to be upgraded to ASM that's compatible with >> Java 8 at some point, >> but our projects are using 5.3, and we don't plan to upgrade to 5.4 for >> various reasons. >> So, if there are no plans for upgrading 5.3 to the new ASM, we need to think >> about >> alternate plans ahead of time. >> >> Also, is there a particular reason why ASM is 'baked in' to plastic, as >> opposed >> to just having a separate maven / gradle dependency on it? >> Seems to be much easier to upgrade if it's a regular dependency rather than >> jarjar'd. >> >> >> On Jan 31, 2014, at 2:04 PM, Joachim Van der Auwera wrote: >> >>> I am currently using Tapestry 5.4 on Java8 by applying the patch given in >>> https://issues.apache.org/jira/browse/TAP5-2214. >>> I have not (yet) found other issues when using Java8. >>> >>> Personally, I would like to see this patch applied, but I understand that >>> including a non-release version of ASM is not ideal. >>> >>> Kind regards, >>> Joachim >>> >>> On 01/31/2014 07:44 PM, Lenny Primak wrote: >>>> Is there a plan to update 5.3.x when Java 8 comes out? >>>> Is it just the matter of the version of ASM that is used or is there >>>> something >>>> else that precludes 5.3.x to run on Java 8? >>>> >>>> Thanks >>>> >>>> >>>> - >>>> 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 > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Tapestry 5.3.x and Java 8
I am trying to find out about 5.3 specifically, not 5.4. I am sure that 5.4 is going to be upgraded to ASM that's compatible with Java 8 at some point, but our projects are using 5.3, and we don't plan to upgrade to 5.4 for various reasons. So, if there are no plans for upgrading 5.3 to the new ASM, we need to think about alternate plans ahead of time. Also, is there a particular reason why ASM is 'baked in' to plastic, as opposed to just having a separate maven / gradle dependency on it? Seems to be much easier to upgrade if it's a regular dependency rather than jarjar'd. On Jan 31, 2014, at 2:04 PM, Joachim Van der Auwera wrote: > I am currently using Tapestry 5.4 on Java8 by applying the patch given in > https://issues.apache.org/jira/browse/TAP5-2214. > I have not (yet) found other issues when using Java8. > > Personally, I would like to see this patch applied, but I understand that > including a non-release version of ASM is not ideal. > > Kind regards, > Joachim > > On 01/31/2014 07:44 PM, Lenny Primak wrote: >> Is there a plan to update 5.3.x when Java 8 comes out? >> Is it just the matter of the version of ASM that is used or is there >> something >> else that precludes 5.3.x to run on Java 8? >> >> Thanks >> >> >> - >> 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
Tapestry 5.3.x and Java 8
Is there a plan to update 5.3.x when Java 8 comes out? Is it just the matter of the version of ASM that is used or is there something else that precludes 5.3.x to run on Java 8? Thanks - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Loop and iterator
What about something similar to varStatus in jsf? > On Jan 29, 2014, at 2:01 PM, "Thiago H de Paula Figueiredo" > wrote: > >> On Wed, 29 Jan 2014 16:17:49 -0200, Dimitris Zenios >> wrote: >> >> I have a list of 8 elements.I want to loop over the elements and every 3 >> elements or at beginning of list to Start with a and end with a >> . >> >> Resulting output should be >> >> >> >> > >> >> >> >> >> >> >> >> >> > >> So i though i will create a mixin that attaches to the loop and adds those >> divs.I managed to almost make it work except one last case.After the last >> element i want to close my previous div even if the index is not % 3.In >> order to know that loop is in the last element i need the iterator of the >> loop. > > I'd use pure DOM rewriting instead. tapestry-xpath is extremely helpful for > these situations. Don't expect the Tapestry team to expose implementation > details: they don't like it. > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.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: Running tapestry 5.4 unit tests with jquery javascript infrastructure provider
Yes. Both me and Thiago found bugs already that are present with jquery but not prototype infrastructure. > On Nov 21, 2013, at 6:53 AM, "Thiago H de Paula Figueiredo" > wrote: > > I think having the build run all test with both infrastructure provides is a > very good idea. > >> On Tue, 19 Nov 2013 21:17:18 -0200, Chris Poulsen >> wrote: >> >> Hi, >> >> I've just been tracking down a small ajaxformloop javascript error in 5.4, >> it turned out that it only happens when using jquery as javascript >> infrastructure provider. >> >> While probing around to nail the error I tried the component in the >> tapestry-core integration/app1 in both modes (jquery/prototype), seeing >> that it only failed with jquery i got curious. >> >> I tried running the core tests with the app1 module in jquery-mode, it >> resulted in 21 errors (my ajaxformloop patch applied - don't know if that >> would show up as a test failure as well), running the tests with prototype >> completes without any errors. >> >> It would probably be a good thing to run all integration tests in both >> modes on a regular basis to get the most out of the test suite. >> >> Also visiting the app1/forminjectordemo in prototype mode results in a >> browser console error about scriptaculous needs a newer prototype version >> or something like that. > > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.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: Discussion: what's left for a beta?
Bugs bugs bugs. There are still at least 100 bugs that are open and haven't been looked at. Some of them serious On Nov 20, 2013, at 6:38 PM, Howard Lewis Ship wrote: > As always, there are endless things I think would be really wonderful to > have, that need to wait for a dot release. > > - A more dynamic WebSockets story > - A built-in RESTful system > > However, in terms of what's left for 5.4 I think it's pretty much > there. Time, I think, to focus on documentation and bug fixing. > > Very interested to see what folks think ...especially if it is accompanied > by a plan or timeline to do the work. > > > -- > 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: Are there published -SNAPSHOT JARs (nightly CI builds or something like that)?
Thank you! On Oct 29, 2013, at 8:25 PM, Bob Harner wrote: > I just updated the > http://tapestry.apache.org/download.htm<http://tapestry.apache.org/download.html>l > page to make it a little easier to find the alpha releases as well as the > nightly snapshot binaries. > > > On Tue, Oct 29, 2013 at 7:07 PM, Lenny Primak wrote: > >> Thank you! That works >> >> On Oct 29, 2013, at 6:41 PM, Andreas Ernst wrote: >> >>> Am 29.10.13 23:03, schrieb Lenny Primak: >>>> I'd like to try the latest T5.4 release that's built by CI. >>>> >>>> Is there a repository that I can point to to be able to access them? >>> >>> I found this: >>> >>> >> https://repository.apache.org/content/repositories/snapshots/org/apache/tapestry/ >>> >>> >>> -- >>> ae | Andreas Ernst | IT Spektrum >>> Postfach 5, 65612 Beselich >>> Schupbacher Str. 32, 65614 Beselich, Germany >>> Tel: +49-6484-91002 Fax: +49-6484-91003 >>> a...@ae-online.de | www.ae-online.de >>> www.tachyon-online.de >>> >>> - >>> 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: Are there published -SNAPSHOT JARs (nightly CI builds or something like that)?
Thank you! That works On Oct 29, 2013, at 6:41 PM, Andreas Ernst wrote: > Am 29.10.13 23:03, schrieb Lenny Primak: >> I'd like to try the latest T5.4 release that's built by CI. >> >> Is there a repository that I can point to to be able to access them? > > I found this: > > https://repository.apache.org/content/repositories/snapshots/org/apache/tapestry/ > > > -- > ae | Andreas Ernst | IT Spektrum > Postfach 5, 65612 Beselich > Schupbacher Str. 32, 65614 Beselich, Germany > Tel: +49-6484-91002 Fax: +49-6484-91003 > a...@ae-online.de | www.ae-online.de > www.tachyon-online.de > > - > 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
Are there published -SNAPSHOT JARs (nightly CI builds or something like that)?
I'd like to try the latest T5.4 release that's built by CI. Is there a repository that I can point to to be able to access them? Thanks - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Tapestry Bugs - How to get them fixed?
Dmitry, if you are using or want to use the FlowLogix library, and have a specific issue with it, please report it via issue tracking. I don't require patch with tests and I look at them all :) The library is meant to be primarily a JEE bridge, so if you really don't want any JEE dependencies, this library is not for you. But... if there is enough interest though, I can split it up into two modules, one JEE and one just Tapestry enhancements. I am hoping not to do this because all of the enhancements should really be in Tapestry itself, and I am hoping to use this thread as a catalyst to get some of the stuff that should be in Tapestry into Tapestry anyway. A lot of people give JEE a bad rap, which mostly stems from EJB 2.1 days (long gone now) The only JEE dependency is the API, which requires no runtime support, if its not used. All other dependencies are not required if they are not used. On Oct 28, 2013, at 3:02 AM, Dmitry Gusev wrote: > By modules I mean not maven/gradle sub projects, but tapestry modules which > are simple Java classes: one module -- one class. No need to add these > modules to auto discovery via manifest. Users may include these modules by > using @SubModule on their AppModules. I see no extra-overhead here. > > Your assumption about "everybody want my fixes" is wrong, I don't want them > in my project if they come with 3rd party library that has tons of extra > dependencies like JEE stuff, etc. > > Also I want the ability to opt-out some fixes if I have better workaround > for them. That was my point. > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Tapestry Bugs - How to get them fixed?
On Oct 27, 2013, at 6:57 PM, Kalle Korhonen wrote: > Well this a marriage made in heaven then. Thiago awhile ago said he'd be > willing to prioritize his bug fixing list based on pay/donation. I think > this might just work but don't be surprised how expensive it is to write > custom software by an expert. I guarantee though you'll be able to get them > fixed quick once the pay is right. I've been doing software development for 25 years. Nothing surprises me anymore, whether on the expensive, or the cheap side. I want to facilitate the solution here. I am going to pay out of my own pocket, because I feel that's how I can contribute to Tapestry more than my time right now. > I think Dmitry is totally right saying > that you should just focus on one issue at a time. If you want to keep it > public, just set a price for a few of your highest priority ones, publish > it here and see if anybody bites. If not, just contact individuals or wait > them to contact you. I would like to keep it in private for now. If Thiago (or any other committer) wants to take this on, please email me. > > Still, you say you don't have time to do it yourself but you have time > write the email. I suspect that in reality, you'd like to get the bug fix > but getting it fixed is just not high enough on your priority list. Yeah, I > totally get the "it takes 10x for me" but even if working on open source > takes time from you, it also gives back. Your next bug fix will be that > much easier and faster and you learn a lot. But then I am on the hook for maintaining it, tracking incompatible changes, etc. for the rest of my life. This happened in 5.3->5.4 transition, every one of my fixes that I have in the FlowLogix library got broken, and I spent countless unpaid hours updating this. I do believe I have and I am contributing a lot in code / time to Tapestry community. I've been answering questions for a long time, wrote a JEE bridge component library, which is Apache licensed, and even helped evangelized Tapestry through networking. > The group of committers is not > an organization whose sole mission and highest priority is to make Tapestry > work for as many people as possible. It's just a group of individuals with > their own missions, desires and priorities. Until your issue scratches the > itch of a committer, it's quite possible it's not going to be anybody > else's top priority any more than yours. Absolutely understandable. Trying to find a solution to the above-described problem. > > Finally, it would have been equally correct to say this problem perpetually > exists in the open source world. Any successful project is struggling with > the same issues. There's always more ideas and new use cases than there are > hands that do the work. Yes, but I think there are too few active committers in Tapestry, for the amount of users / issues that come up. Other open source projects are a lot more active about fixing issues with a lot more committers doing it. > > >> >>> >>>> I originally built the FlowLogix library... >>>> Most of the functionality in there now is actually workarounds for >>> various bugs and missing features in Tapestry. >>> >>> Tapestry has one good ability to write workarounds for the bugs in client >>> code (via service overrides, decorators, etc.). >>> If you have some of the bugs fixed in FlowLogix I'd recommend to separate >>> the fixes to some FlowLogix sub-project and write some guides to >>> corresponding JIRA issues on how to apply the workarounds you've already >>> implemented. >> >> I have all fixes documented pretty well in the wiki. >> As we go forward to T5.4 and beyond, I don't see that trajectory >> as sustainable in the amount of time that I have to spend on this. >> Also, if you do split up the library into many modules, you will have 10 >> of them >> or so, a nightmare to maintain. >> None of these bug fixes are something that somebody wouldn't want anyway, >> no reason to make them that granular, the whole library is only 100k >> >>> >>> I'm sure it is possible to write most of the workarounds as a separate >>> tapestry modules. I'd maybe even used strategy of one tapestry submodule >>> per one bugfix. Maybe name those modules like FixForXXX and if I want >> your >>> workaround in my project I'd add this modules as a submodule to my >>> AppModule. >>> >> >> Already done in FlowLogix library (see my comments re: one-per-module >> above) >> that would make too many modules, and I don't have time to
Re: Tapestry Bugs - How to get them fixed?
If I had to pick top 3 issues, it would be these: https://issues.apache.org/jira/browse/TAP5-2208 https://issues.apache.org/jira/browse/TAP5-2182 and incorporate JQuery DatePicker into Tapestry-core On Oct 27, 2013, at 10:03 AM, Lenny Primak wrote: > Quick Jira search reveals bugs I care about: > Basically, this is a result of a search of issues that > are reported by me, voted on my me or watched by me: > > https://issues.apache.org/jira/browse/TAP5-2208 > https://issues.apache.org/jira/browse/TAP5-2197 > https://issues.apache.org/jira/browse/TAP5-2196 > https://issues.apache.org/jira/browse/TAP5-2188 > https://issues.apache.org/jira/browse/TAP5-2187 > https://issues.apache.org/jira/browse/TAP5-2185 > https://issues.apache.org/jira/browse/TAP5-2182 > https://issues.apache.org/jira/browse/TAP5-2173 > https://issues.apache.org/jira/browse/TAP5-2172 > https://issues.apache.org/jira/browse/TAP5-2168 > https://issues.apache.org/jira/browse/TAP5-2167 > https://issues.apache.org/jira/browse/TAP5-2166 > https://issues.apache.org/jira/browse/TAP5-2158 > https://issues.apache.org/jira/browse/TAP5-2140 > https://issues.apache.org/jira/browse/TAP5-2027 > https://issues.apache.org/jira/browse/TAP5-1918 > https://issues.apache.org/jira/browse/TAP5-1883 > https://issues.apache.org/jira/browse/TAP5-1845 > https://issues.apache.org/jira/browse/TAP5-1803 > https://issues.apache.org/jira/browse/TAP5-1772 > https://issues.apache.org/jira/browse/TAP5-1741 > https://issues.apache.org/jira/browse/TAP5-1661 > https://issues.apache.org/jira/browse/TAP5-1640 > https://issues.apache.org/jira/browse/TAP5-1634 > https://issues.apache.org/jira/browse/TAP5-1611 > https://issues.apache.org/jira/browse/TAP5-1606 > https://issues.apache.org/jira/browse/TAP5-1512 > https://issues.apache.org/jira/browse/TAP5-1404 > https://issues.apache.org/jira/browse/TAP5-970 > https://issues.apache.org/jira/browse/TAP5-805 > > This is comprehensive list, not ordered by priority. > > More comments interspersed... > > > On Oct 27, 2013, at 3:35 AM, Dmitry Gusev wrote: >> >> I'm sure if you prepare well-tested pull request it will be accepted, but >> you have to spend some time on it -- this is the price you should pay for >> using open source for free. > > I don't have time for that. I am willing to pay to get my bugs fixed, > out of my own pocket (my clients won't pay for it) > >> >>> I originally built the FlowLogix library... >>> Most of the functionality in there now is actually workarounds for >> various bugs and missing features in Tapestry. >> >> Tapestry has one good ability to write workarounds for the bugs in client >> code (via service overrides, decorators, etc.). >> If you have some of the bugs fixed in FlowLogix I'd recommend to separate >> the fixes to some FlowLogix sub-project and write some guides to >> corresponding JIRA issues on how to apply the workarounds you've already >> implemented. > > I have all fixes documented pretty well in the wiki. > As we go forward to T5.4 and beyond, I don't see that trajectory > as sustainable in the amount of time that I have to spend on this. > Also, if you do split up the library into many modules, you will have 10 of > them > or so, a nightmare to maintain. > None of these bug fixes are something that somebody wouldn't want anyway, > no reason to make them that granular, the whole library is only 100k > >> >> I'm sure it is possible to write most of the workarounds as a separate >> tapestry modules. I'd maybe even used strategy of one tapestry submodule >> per one bugfix. Maybe name those modules like FixForXXX and if I want your >> workaround in my project I'd add this modules as a submodule to my >> AppModule. >> > > Already done in FlowLogix library (see my comments re: one-per-module above) > that would make too many modules, and I don't have time to create / maintain > all of them > >> >> >> >> On Sun, Oct 27, 2013 at 10:40 AM, Lenny Primak wrote: >> >>> Some of the issues I am having is more design-oriented, >>> and a patch would not be a simple thing to do. >>> >>> Also, in order to produce a patch (with tests) a lot of work needs to >>> happen. >>> That work, for example, for someone like me will take 10x as long as >>> for someone already familiar with the Tapestry code, or the part of the >>> code that I am trying to fix. >>> When someone already has built Tapestry environment / Selenium test >>> environment, >>> i.e. a Tapestry committer, the work will take much sh
Re: Tapestry Bugs - How to get them fixed?
Quick Jira search reveals bugs I care about: Basically, this is a result of a search of issues that are reported by me, voted on my me or watched by me: https://issues.apache.org/jira/browse/TAP5-2208 https://issues.apache.org/jira/browse/TAP5-2197 https://issues.apache.org/jira/browse/TAP5-2196 https://issues.apache.org/jira/browse/TAP5-2188 https://issues.apache.org/jira/browse/TAP5-2187 https://issues.apache.org/jira/browse/TAP5-2185 https://issues.apache.org/jira/browse/TAP5-2182 https://issues.apache.org/jira/browse/TAP5-2173 https://issues.apache.org/jira/browse/TAP5-2172 https://issues.apache.org/jira/browse/TAP5-2168 https://issues.apache.org/jira/browse/TAP5-2167 https://issues.apache.org/jira/browse/TAP5-2166 https://issues.apache.org/jira/browse/TAP5-2158 https://issues.apache.org/jira/browse/TAP5-2140 https://issues.apache.org/jira/browse/TAP5-2027 https://issues.apache.org/jira/browse/TAP5-1918 https://issues.apache.org/jira/browse/TAP5-1883 https://issues.apache.org/jira/browse/TAP5-1845 https://issues.apache.org/jira/browse/TAP5-1803 https://issues.apache.org/jira/browse/TAP5-1772 https://issues.apache.org/jira/browse/TAP5-1741 https://issues.apache.org/jira/browse/TAP5-1661 https://issues.apache.org/jira/browse/TAP5-1640 https://issues.apache.org/jira/browse/TAP5-1634 https://issues.apache.org/jira/browse/TAP5-1611 https://issues.apache.org/jira/browse/TAP5-1606 https://issues.apache.org/jira/browse/TAP5-1512 https://issues.apache.org/jira/browse/TAP5-1404 https://issues.apache.org/jira/browse/TAP5-970 https://issues.apache.org/jira/browse/TAP5-805 This is comprehensive list, not ordered by priority. More comments interspersed... On Oct 27, 2013, at 3:35 AM, Dmitry Gusev wrote: > > I'm sure if you prepare well-tested pull request it will be accepted, but > you have to spend some time on it -- this is the price you should pay for > using open source for free. I don't have time for that. I am willing to pay to get my bugs fixed, out of my own pocket (my clients won't pay for it) > >> I originally built the FlowLogix library... >> Most of the functionality in there now is actually workarounds for > various bugs and missing features in Tapestry. > > Tapestry has one good ability to write workarounds for the bugs in client > code (via service overrides, decorators, etc.). > If you have some of the bugs fixed in FlowLogix I'd recommend to separate > the fixes to some FlowLogix sub-project and write some guides to > corresponding JIRA issues on how to apply the workarounds you've already > implemented. I have all fixes documented pretty well in the wiki. As we go forward to T5.4 and beyond, I don't see that trajectory as sustainable in the amount of time that I have to spend on this. Also, if you do split up the library into many modules, you will have 10 of them or so, a nightmare to maintain. None of these bug fixes are something that somebody wouldn't want anyway, no reason to make them that granular, the whole library is only 100k > > I'm sure it is possible to write most of the workarounds as a separate > tapestry modules. I'd maybe even used strategy of one tapestry submodule > per one bugfix. Maybe name those modules like FixForXXX and if I want your > workaround in my project I'd add this modules as a submodule to my > AppModule. > Already done in FlowLogix library (see my comments re: one-per-module above) that would make too many modules, and I don't have time to create / maintain all of them > > > > On Sun, Oct 27, 2013 at 10:40 AM, Lenny Primak wrote: > >> Some of the issues I am having is more design-oriented, >> and a patch would not be a simple thing to do. >> >> Also, in order to produce a patch (with tests) a lot of work needs to >> happen. >> That work, for example, for someone like me will take 10x as long as >> for someone already familiar with the Tapestry code, or the part of the >> code that I am trying to fix. >> When someone already has built Tapestry environment / Selenium test >> environment, >> i.e. a Tapestry committer, the work will take much shorter amount of time. >> With all due respect, this isn't the best use of my time right now, >> as I have booked for more work than I can do in a day, every day. >> I want to be working on my clients' code, not Tapestry code. >> I don't want to have to get Selenium to work (which never worked in my >> environment) >> Our clients are not that advanced and we don't have integration testing, >> but we do a lot of unit testing. >> I just want to use Tapestry, report issues, and have them fixed. >> >> This problem perpetually exists in the Tapestry community, >> there are plenty of (valid) reasons for it (as you me
Re: Tapestry Bugs - How to get them fixed?
Some of the issues I am having is more design-oriented, and a patch would not be a simple thing to do. Also, in order to produce a patch (with tests) a lot of work needs to happen. That work, for example, for someone like me will take 10x as long as for someone already familiar with the Tapestry code, or the part of the code that I am trying to fix. When someone already has built Tapestry environment / Selenium test environment, i.e. a Tapestry committer, the work will take much shorter amount of time. With all due respect, this isn't the best use of my time right now, as I have booked for more work than I can do in a day, every day. I want to be working on my clients' code, not Tapestry code. I don't want to have to get Selenium to work (which never worked in my environment) Our clients are not that advanced and we don't have integration testing, but we do a lot of unit testing. I just want to use Tapestry, report issues, and have them fixed. This problem perpetually exists in the Tapestry community, there are plenty of (valid) reasons for it (as you mentioned) but I am looking for a solution, which doesn't involve me spending more and more time on it (which I certainly do not have) On Oct 27, 2013, at 12:00 AM, Kalle Korhonen wrote: > Most if not all of the committers are in the same boat as you are. They > have already risked their own time and energy to patch issues themselves so > many times that the previous committers thought it's simply easier to give > commit access to this person than to keep applying his patches. > > All software has bugs but Tapestry's codebase is in general very mature, > well tested and well thought out. Tapestry committers have, for various > reasons, decided that the benefits of using Tapestry outweigh the > drawbacks, even when patching issues themselves. Everybody needs to do > their own benefit analysis. In terms of user base, Tapestry has one of the > largest among Java web frameworks. > > The most certain way of getting your issue fixed is supplying a patch with > test. It doesn't always get applied or it doesn't get applied without > changes. If you think it's difficult to get a patch applied to Tapestry, > you should try kernel development first. > > Kalle > > > > On Sat, Oct 26, 2013 at 6:31 PM, Lenny Primak wrote: > >> Hi guys, >> >> I am struggling with a problem - how to get bugs (that I care about) fixed? >> I am building web apps for clients that run on Tapestry. >> I am finding that I am spending more and more time working around Tapestry >> bugs. >> The time that I spend fixing / working around bugs in Tapestry is the time >> I don't spend building >> and fixing my own applications. This isn't a good situation. >> >> I originally built the FlowLogix library to bridge Tapestry with JEE, and >> Shiro (via Tapestry-Security) >> Most of the functionality in there now is actually workarounds for various >> bugs and missing features in Tapestry. >> I always file a JIRA for every one of them. Minority gets fixed (after >> much begging) but majority isn't getting fixed. >> >> I know there are a lot of JIRA issues and few committers. I also know I >> can submit patches, but this can be dicey as well, >> as that takes committers' time and energy. Risk for me is that I can't >> spend time creating patches that don't get applied, or >> get rejected because I don't have a separate test (even though it's mostly >> enough that it doesn't cause a regression, >> which is covered by other tests) >> >> I also know Tapestry community is small, and volunteer, so this problem >> doesn't really surprise me. >> Right now, I am at a point that is getting unsustainable in this manner, >> especially since so many changes are >> happening in T5.4, which brings much more work and more bugs to fix. >> >> I'd like to know if any committers want to help solve this problem? I >> know it can be solved. >> What can be the motivating factor in getting these bugs fixed? >> >> I will even go as far as paying for the fixes. My clients won't pay for >> me to fix Tapestry, >> so I would have to pay out of my own pocket, just so I don't have to lose >> time fixing Tapestry myself. >> Any other suggestions? >> >> Same applies to Tynamo project as well. >> >> >> - >> 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
Tapestry Bugs - How to get them fixed?
Hi guys, I am struggling with a problem - how to get bugs (that I care about) fixed? I am building web apps for clients that run on Tapestry. I am finding that I am spending more and more time working around Tapestry bugs. The time that I spend fixing / working around bugs in Tapestry is the time I don't spend building and fixing my own applications. This isn't a good situation. I originally built the FlowLogix library to bridge Tapestry with JEE, and Shiro (via Tapestry-Security) Most of the functionality in there now is actually workarounds for various bugs and missing features in Tapestry. I always file a JIRA for every one of them. Minority gets fixed (after much begging) but majority isn't getting fixed. I know there are a lot of JIRA issues and few committers. I also know I can submit patches, but this can be dicey as well, as that takes committers' time and energy. Risk for me is that I can't spend time creating patches that don't get applied, or get rejected because I don't have a separate test (even though it's mostly enough that it doesn't cause a regression, which is covered by other tests) I also know Tapestry community is small, and volunteer, so this problem doesn't really surprise me. Right now, I am at a point that is getting unsustainable in this manner, especially since so many changes are happening in T5.4, which brings much more work and more bugs to fix. I'd like to know if any committers want to help solve this problem? I know it can be solved. What can be the motivating factor in getting these bugs fixed? I will even go as far as paying for the fixes. My clients won't pay for me to fix Tapestry, so I would have to pay out of my own pocket, just so I don't have to lose time fixing Tapestry myself. Any other suggestions? Same applies to Tynamo project as well. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: The Bootstrap Backward Compatibility Problem
I was the one who pestered you :)
I also like this idea, and now the FormHorizontal mixin is working just like
you suggested.
On Oct 23, 2013, at 9:04 AM, Barry Books wrote:
> When I first wrote the tapestry-bootstrap module someone on the list
> pestered me (thanks) to make it backward compatible with the current
> components so you could have both Bootstrap and the older Tapestry
> components on the same page. After some tinkering I discovered it was for
> the most part possible. The biggest issue seems to be something in
> Prototype causes a problem with the Bootstrap menus.
>
> I've been using Bootstrap the since the 1.0 version and I'm currently
> porting my last non Bootstrap web site to 5.4 and Bootstrap. I'm a big
> Bootstrap fan but I can see it's not for everybody. I would also say for
> better or worse the Bootstrap project does seem to worry too much about
> backward compatibility.
>
> At this point I'm happy with the direction of Tapestry and I think the
> addition of Bootstrap solves more problems than it causes.
>
> However I do think it could be better so here is my suggestion
>
> 1. Components should have no framework specific html elements and no css
> 2. I would make a data attribute called data-tapestry-type contain the
> Tapestry component type.
> 3. Attach a mixin to all components that calls a service to add the
> framework specific markup
> 4. Create a strategy service so various framework markups can be supported.
> 5. Each framework strategy service is a pipeline that takes a markup writer
> and modifies the DOM as needed.
> 6. Create a property to define the default framework.
>
> This allows any component to be rendered for any framework. It also
> supports new components by adding services to the framework pipeline. You
> can also contribute site specific customization of components. Lastly it
> solves the markup backward compatibility problem because the default markup
> is not specific to any framework and does not need to change.
>
> This is similar to how the current tapestry-bootstrap modules works.
>
> The backend implementation can be a bit complex but most developers could
> just drop in the framework module they want and the site magically converts
> to that framework.
>
> I did have some issues with the existing components when I went down this
> path. There are some inconsistencies in when components add to the markup
> writer but I think these could all be resolved. For example the outer
> element should always be started before the mixin's beginRender method.
> With a bit more consistency I think all framework specific markup could be
> added with a mixin like
>
> private Element outerElement;
>
> @Environmental
> private Framework framework;
>
> @BeginRender
> void beginRender(MarkupWriter writer) {
> outerElement = writer.getElement();
> }
>
> @CleanupRender
> void cleanupRender(MarkupWriter writer) {
> framework.cleanup(framework, outerElement, writer);
> }
>
> Personally I would not advocate this change at this point. I think the
> current 5.4 path is fine. If there is enough interest it might be
> interesting in 5.4.1 and along with a tapestry-legacy framework module
> could be helpful for people with older sites wanting to upgrade to 5.4
>
> Barry
>
>
> On Tue, Oct 22, 2013 at 11:59 PM, Lenny Primak wrote:
>
>> I am glad I am not the only one seeing this.
>> It's not an easy problem to solve though.
>> And, I am not one of those people that want 100% compatibility
>> (hence I would gladly have Tapestry 6)
>>
>> I am in the process of converting an app to Tapestry 5.4,
>> Having never used bootstrap, and not being a web designer myself,
>> it presented a challenge, but not insurmountable one.
>> The ongoing problem is indeed that the markup will change over time,
>> and maintaining compatibility will be problematic.
>>
>> Right now, My particular issue is beaneditform with parameters
>> isn't generating proper bootstrap markup.
>> I am sure there will be other issues like this that I discover.
>>
>> On Oct 22, 2013, at 9:21 PM, Bob Harner wrote:
>>
>>> For new projects it's very nice that Tapestry 5.4 uses and includes
>>> Bootstrap. But for existing 5.2 and 5.3 projects not already using
>>> Bootstrap (which is probably the vast majority), upgrading to 5.4
>> requires
>>> a burdensome amount of CSS and HTML changes. Even if you go the route of
>>> eliminating the Bootstrap CSS file (which for large existing apps may be
>>> the only practical option), you still need to come up with all new CSS
>>> rules for the
Re: The Bootstrap Backward Compatibility Problem
I am glad I am not the only one seeing this.
It's not an easy problem to solve though.
And, I am not one of those people that want 100% compatibility
(hence I would gladly have Tapestry 6)
I am in the process of converting an app to Tapestry 5.4,
Having never used bootstrap, and not being a web designer myself,
it presented a challenge, but not insurmountable one.
The ongoing problem is indeed that the markup will change over time,
and maintaining compatibility will be problematic.
Right now, My particular issue is beaneditform with parameters
isn't generating proper bootstrap markup.
I am sure there will be other issues like this that I discover.
On Oct 22, 2013, at 9:21 PM, Bob Harner wrote:
> For new projects it's very nice that Tapestry 5.4 uses and includes
> Bootstrap. But for existing 5.2 and 5.3 projects not already using
> Bootstrap (which is probably the vast majority), upgrading to 5.4 requires
> a burdensome amount of CSS and HTML changes. Even if you go the route of
> eliminating the Bootstrap CSS file (which for large existing apps may be
> the only practical option), you still need to come up with all new CSS
> rules for the built-in Tapestry components -- Grid, BeanEditor, Palette,
> etc -- on your own.
>
> Back in August, Tapestry 5.4-alpha-18 switched from Bootstrap 2 to
> Bootstrap 3. Since 2 and 3 are incompatible, this meant Howard had to do
> another round of disruptive, non-backward-compatible changes to Tapestry
> components (see his commits between Aug 21 and Sep 3, for TAP5-2151), and
> all users tracking the alphas had to adapt their apps to use Bootstrap 3.
> What happens if you wanted to stick with Bootstrap 2? What happens when
> Bootstrap 4 comes out?
>
> As we all know, one of Tapestry's "core principles" is backward
> compatibility -- which means upgrades should be very easy.
>
> It occurred to me that Tapestry already has a built-in means for rendering
> alternate content for the same components -- the template skinning
> mechanism (http://blog.tapestry5.de/index.php/2011/06/24/template-skinning/).
> Could this mechanism be used for the Bootstrap compatibility problem?
> Could Tapestry use Template Skinning internally to choose between
> "Bootstrap 2", "Bootstrap 3" and "Tapestry Classic" templates based on a
> configured symbol?
>
> One obstacle is that most of Tapestry's built-in components render the CSS
> class names and layout directly from the component class (using
> MarkupWriter) rather than using a template. In the cases I looked at,
> though, this could be changed. For example, TextField's has this:
>
> writer.element("input","type",type,"name", getControlName(),"class",
> "form-control","id", getClientId(),"value", value,"size", getWidth());
>
> but that could be moved to a TextField.tml file:
>
> id="${clientId}" value="${value}" size="${width}" />
>
> It's not quite that simple, of course. The templates might end up with some
> "if" statements wrapped around some sections to handle logic that now
> resides in the component class. But that's okay, because it still allows us
> to have alternate versions of the templates for different skins/themes.
>
> By my count there are 14 components that have Bootstrap-related rendering
> (Alerts, BeanEditForm, BeanEditor, Checkbox, Checklist, ControlGroup,
> DateField, Errors, Palette, PasswordField, Radio, Select, TextArea,
> TextField), and of those, only BeanEditForm/BeanEditor, Checklist use
> templates.
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
JIRA admins - please reopen this bug
https://issues.apache.org/jira/browse/TAP5-1408 Thanks - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Proposal for a list of modules recommended by the Tapestry team
Perhaps its time to finish it. It looks good from the screen shots that I've seen. Perhaps it can be seen as community building project. On Oct 9, 2013, at 2:50 PM, Thiago H de Paula Figueiredo wrote: > On Wed, 09 Oct 2013 15:18:53 -0300, Lenny Primak > wrote: > >> Bob Harner has already something called a module registry. >> I think it should be adopted by Tapestry documentation project. >> No need to create anything new here. > > I don't think he actually finished it. At least I can't recall he mentioned > that it was ready for use or test. https://github.com/bobharner/ComponentWorld > >> Also, even though github is 'in' right now, not everything is on github. >> lots of projects are hosted on google code, sourceforge, etc. >> Forcing or pseudo-forcing (i.e. if you are not on github you are not in the >> registry) isn't a good idea. > > We never said that projects outside GitHub wouldn't be included. We just said > that *most* projects are on GitHub, so it makes sense to store this registry > there. > >> >> On Oct 9, 2013, at 8:42 AM, Thiago H de Paula Figueiredo wrote: >> >>> On Wed, 09 Oct 2013 07:50:21 -0300, Barry Books wrote: >>> >>>> I think there needs to be some repository of 3rd party modules >>> >>> Agreed. There's http://tapestry.apache.org/third-party-modules.html, linked >>> on the documentation page. It may not be ideal, but at least that's a start. >>> >>>> and I don't think >>>> the apache site is the place for that. I've been thinking about creating a >>>> github project and using that as a way to document what's available. If >>>> you have a 3rd party module you could be a contributor and I think it >>>> would be pretty easy to create one place to go for info, create bug >>>> reports etc. >>>> I think this could be one step to more cooperation. >>> >>> I like the idea. I have some ideas about the distributed configuration JIRA >>> you posted that would make it easier to implement the project above. >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> Tapestry, Java and Hibernate consultant and developer >>> http://machina.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 >> > > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.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: Proposal for a list of modules recommended by the Tapestry team
Bob Harner has already something called a module registry. I think it should be adopted by Tapestry documentation project. No need to create anything new here. Also, even though github is 'in' right now, not everything is on github. lots of projects are hosted on google code, sourceforge, etc. Forcing or pseudo-forcing (i.e. if you are not on github you are not in the registry) isn't a good idea. On Oct 9, 2013, at 8:42 AM, Thiago H de Paula Figueiredo wrote: > On Wed, 09 Oct 2013 07:50:21 -0300, Barry Books wrote: > >> I think there needs to be some repository of 3rd party modules > > Agreed. There's http://tapestry.apache.org/third-party-modules.html, linked > on the documentation page. It may not be ideal, but at least that's a start. > >> and I don't think >> the apache site is the place for that. I've been thinking about creating a >> github project and using that as a way to document what's available. If you >> have a 3rd party module you could be a contributor and I think it would be >> pretty easy to create one place to go for info, create bug reports etc. >> I think this could be one step to more cooperation. > > I like the idea. I have some ideas about the distributed configuration JIRA > you posted that would make it easier to implement the project above. > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.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: Proposal for a list of modules recommended by the Tapestry team
As much as I hate to say it, just like with the book idea, the Tapestry ecosystem isn't big enough to have an 'endorsed by' program or any kind of certification. Wish it wasn't so but it is. For example, let's take CDI support. There are at least 3 implementations, with equal quality as far as I know. Who is going to be the judge which one gets the stamp of approval? PMC? All committers? Users of the list? Do you think all three should get approval? Do you think people are actually going to take a look at all the modules, really take a look at them for quality? I really don't see this as sustainable long term. The problem here is more systemic. There is not enough cooperation in the Tapestry world. There are not enough active committers. Even many 3rd party modules are very duplicative because their owners want 'their' code 'pure' and not 'contaminate / dump' other's people's perceived 'inferior' code into their projects. The solution here is more cooperation and less 'certification' Thiago, as far as your own modules, I think you are doing great work, and you should put 'Tapestry Committer and PMC member' with your modules. (at least I think you are :) That should carry more than enough weight with people. On Oct 8, 2013, at 3:09 PM, Thiago H de Paula Figueiredo wrote: > Hi! > > There's an interesting discussion between me and Pieter in > https://issues.apache.org/jira/browse/TAP5-64. The gist of it is that he > wants portlets support in Tapestry, there's tapestry5-portlets, which is > written by at least two Tapestry committers, but the consensus here is to not > add more modules to the Tapestry project itself due to the time to support > it. His argument, and I kind of agree with him, is that having > tapestry5-portlets in the Tapestry project is a seal of quality for the > portlet support. > > I propose a compromise: in the Tapestry documentation site, a page containing > third-party Tapestry and Tapestry-IoC modules which the Tapestry team > recommends due to their proven quality. For example, tapestry-security is > written by Kalle Korhonen, which is both a Tapestry and Shiro committer. Or > tapestry-url-rewriter, written by me and Robert Zeigler and not in Tapestry > itself anymore. For a given module to be listed there, I suggest that we > carry a vote just like we do with new committers. In addition, we could have > a page in the Tapestry documentation with some documentation. > > What do you guys think? > > Cheers! > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.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: [jira] [Created] (TAP5-2187) CSS relative URL rewriting isn't lenient enough
That's the first thing I tried when implementing that particular project. It didn't work for reasons too numerous to mention here. And it's not a matter of bugs, etc. The design dictates that its better to do it the way I am doing it. But this is a digression from the topic at hand. On Sep 24, 2013, at 5:06 PM, Barry Books wrote: > I've put GWT projects in their own war and included them with Tapestry > projects. When I include them I usually put them in a GWT directory and > tell Tapestry to ignore it. > > > On Tue, Sep 24, 2013 at 11:35 AM, Lenny Primak wrote: > >> Because the GWT parts talk to the Tapestry parts, so they have to be in >> the same relative path. >> Also, Tapestry has some nice things like forever-caching etc. that I like >> to take advantage of >> >> On Sep 24, 2013, at 8:49 AM, Barry Books wrote: >> >>> I could go either way on this but I can see why you want to turn this >> off. >>> FYI I don't deploy my GWT client code thru Tapestry at all. Is there any >>> reason why you do? >>> >>> >>> On Tue, Sep 24, 2013 at 7:33 AM, Thiago H de Paula Figueiredo < >>> thiag...@gmail.com> wrote: >>> >>>> On Mon, 23 Sep 2013 21:43:55 -0300, Lenny Primak < >> lpri...@hope.nyc.ny.us> >>>> wrote: >>>> >>>> I can't. The whole tree gets reworked by the GWT compiler plugin at the >>>>> end. Putting an extra all-or-nothing check for CSS just makes Tapestry >>>>> harder to use with no real benefit on the other side. >>>>> Also, this is clearly incompatible with Tapestry's previous behavior. >>>>> >>>> >>>> I agree with Lenny about this. The normal behavior of CSS is to not fail >>>> when some linked resource isn't found. >>>> >>>> >>>> -- >>>> Thiago H. de Paula Figueiredo >>>> >>>> >> --**--**- >>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org< >> 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: [jira] [Created] (TAP5-2187) CSS relative URL rewriting isn't lenient enough
Because the GWT parts talk to the Tapestry parts, so they have to be in the same relative path. Also, Tapestry has some nice things like forever-caching etc. that I like to take advantage of On Sep 24, 2013, at 8:49 AM, Barry Books wrote: > I could go either way on this but I can see why you want to turn this off. > FYI I don't deploy my GWT client code thru Tapestry at all. Is there any > reason why you do? > > > On Tue, Sep 24, 2013 at 7:33 AM, Thiago H de Paula Figueiredo < > thiag...@gmail.com> wrote: > >> On Mon, 23 Sep 2013 21:43:55 -0300, Lenny Primak >> wrote: >> >> I can't. The whole tree gets reworked by the GWT compiler plugin at the >>> end. Putting an extra all-or-nothing check for CSS just makes Tapestry >>> harder to use with no real benefit on the other side. >>> Also, this is clearly incompatible with Tapestry's previous behavior. >>> >> >> I agree with Lenny about this. The normal behavior of CSS is to not fail >> when some linked resource isn't found. >> >> >> -- >> Thiago H. de Paula Figueiredo >> >> --**--**- >> To unsubscribe, e-mail: >> dev-unsubscribe@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: [jira] [Created] (TAP5-2187) CSS relative URL rewriting isn't lenient enough
I can't. The whole tree gets reworked by the GWT compiler plugin at the end. Putting an extra all-or-nothing check for CSS just makes Tapestry harder to use with no real benefit on the other side. Also, this is clearly incompatible with Tapestry's previous behavior. On Sep 23, 2013, at 8:32 PM, Howard Lewis Ship wrote: > Warnings get ignored and turn into even worse problems later. Errors have > to be attended to. Drop an empty .PNG in the right location and you'll be > the happier for it. > > > On Mon, Sep 23, 2013 at 2:33 PM, Thiago H de Paula Figueiredo < > thiag...@gmail.com> wrote: > >> On Mon, 23 Sep 2013 18:11:11 -0300, Howard Lewis Ship >> wrote: >> >> When parsing the .css file, when it finds url() elements, it must resolve >>> the target of the url() and generate a complete path to the asset, >>> including the checksum that goes in the URL, and that requires the file >>> to actually exist. >>> >> >> So I think what Lenny reported is a bug. A CSS file is still valid even if >> it refers to non-existent assets. What about logging a warning and keeping >> the invalid reference unchanged (which is actually Lenny's suggestion)? >> >> >>> >>> On Mon, Sep 23, 2013 at 12:26 PM, Thiago H de Paula Figueiredo < >>> thiag...@gmail.com> wrote: >>> >>> On Mon, 23 Sep 2013 16:19:14 -0300, Lenny Primak >>>> >>>> wrote: >>>> >>>> Yes it does. It says that .png file was not found, >>>> >>>>> but the exception is while loading the .css file. >>>>> >>>>> >>>> Weird. It does sound like a bug. >>>> >>>> >>>> There are lots of .css files that have errors / missing files in them, >>>> >>>>> not under my control. >>>>> If I had to write a RequestFilter for each and every one of them, it >>>>> would be nightmare. >>>>> >>>>> >>>> If there was some pattern, you could use the same RequestFilter for all >>>> them. >>>> >>>> >>>> The new 5.4 CSS URL rewriting mechanism should just leave the links to >>>> >>>>> unknown assets alone, >>>>> that's what I mean by 'ignoring' it. Just like the browser does when it >>>>> loads CSS files. >>>>> >>>>> >>>> You imply the CSS URL rewriting checks whether referenced files exist or >>>> not. Have you checked this is correct? I'm not sure and I haven't checked >>>> yet. >>>> >>>> >>>> On Sep 23, 2013, at 3:13 PM, Thiago H de Paula Figueiredo wrote: >>>>> >>>>> Hi, Lenny! >>>>> >>>>>> >>>>>> Have you checked if Tapestry throws any exceptions? After all, this is >>>>>> an HTTP 500, which means internal error. >>>>>> >>>>>> I don't know why you mean by "ignore". Did you mean raise a 404 error? >>>>>> >>>>>> A workaround would be to add a RequestFilter or Dispatcher that checks >>>>>> for that non-existent URL and do something about it. >>>>>> >>>>>> On Sun, 22 Sep 2013 22:41:02 -0300, Lenny Primak (JIRA) < >>>>>> j...@apache.org> >>>>>> wrote: >>>>>> >>>>>> Lenny Primak created TAP5-2187: >>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>>Summary: CSS relative URL rewriting isn't lenient enough >>>>>>>Key: TAP5-2187 >>>>>>>URL: https://issues.apache.org/ >>>>>>> jira/browse/TAP5-2187<https://issues.apache.org/**jira/browse/TAP5-2187> >>>>>>> <https://**issues.apache.org/jira/browse/**TAP5-2187<https://issues.apache.org/jira/browse/TAP5-2187> >>>>>>>> >>>>>>> >>>>>>>Project: Tapestry 5 >>>>>>> Issue Type: Bug >>>>>>> Components: tapestry-core >>>>>>> Affects Versions: 5.4 >>>>>>> Reporter: Lenny Primak >>>>>>> >>>>>>> >>>>>>> I am tryin
Re: [jira] [Created] (TAP5-2187) CSS relative URL rewriting isn't lenient enough
Yes but if the URL isn't there the whole CSS file shouldn't blow up but unresolved reference should be just left untouched. > On Sep 23, 2013, at 5:11 PM, Howard Lewis Ship wrote: > > When parsing the .css file, when it finds url() elements, it must resolve > the target of the url() and generate a complete path to the asset, > including the checksum that goes in the URL, and that requires the file to > actually exist. > > > On Mon, Sep 23, 2013 at 12:26 PM, Thiago H de Paula Figueiredo < > thiag...@gmail.com> wrote: > >> On Mon, 23 Sep 2013 16:19:14 -0300, Lenny Primak >> wrote: >> >> Yes it does. It says that .png file was not found, >>> but the exception is while loading the .css file. >> >> Weird. It does sound like a bug. >> >> >> There are lots of .css files that have errors / missing files in them, >>> not under my control. >>> If I had to write a RequestFilter for each and every one of them, it >>> would be nightmare. >> >> If there was some pattern, you could use the same RequestFilter for all >> them. >> >> >> The new 5.4 CSS URL rewriting mechanism should just leave the links to >>> unknown assets alone, >>> that's what I mean by 'ignoring' it. Just like the browser does when it >>> loads CSS files. >> >> You imply the CSS URL rewriting checks whether referenced files exist or >> not. Have you checked this is correct? I'm not sure and I haven't checked >> yet. >> >> >>> On Sep 23, 2013, at 3:13 PM, Thiago H de Paula Figueiredo wrote: >>> >>> Hi, Lenny! >>>> >>>> Have you checked if Tapestry throws any exceptions? After all, this is >>>> an HTTP 500, which means internal error. >>>> >>>> I don't know why you mean by "ignore". Did you mean raise a 404 error? >>>> >>>> A workaround would be to add a RequestFilter or Dispatcher that checks >>>> for that non-existent URL and do something about it. >>>> >>>> On Sun, 22 Sep 2013 22:41:02 -0300, Lenny Primak (JIRA) >>>> wrote: >>>> >>>> Lenny Primak created TAP5-2187: >>>>> --** >>>>> >>>>>Summary: CSS relative URL rewriting isn't lenient enough >>>>>Key: TAP5-2187 >>>>>URL: >>>>> https://issues.apache.org/**jira/browse/TAP5-2187<https://issues.apache.org/jira/browse/TAP5-2187> >>>>>Project: Tapestry 5 >>>>> Issue Type: Bug >>>>> Components: tapestry-core >>>>> Affects Versions: 5.4 >>>>> Reporter: Lenny Primak >>>>> >>>>> >>>>> I am trying to integrate an existing GWT framework as tapestry >>>>> components. >>>>> One of the .css files its trying to load references an non-existent >>>>> .png file. >>>>> Instead of just ignoring it, Tapestry produces a 500 error loading the >>>>> .css file, >>>>> which I don't believe there is a workaround for. >>>>> >>>>> -- >>>>> This message is automatically generated by JIRA. >>>>> If you think it was sent incorrectly, please contact your JIRA >>>>> administrators >>>>> For more information on JIRA, see: http://www.atlassian.com/** >>>>> software/jira <http://www.atlassian.com/software/jira> >>>> >>>> >>>> -- >>>> Thiago H. de Paula Figueiredo >>>> >>>> --**--** >>>> - >>>> To unsubscribe, e-mail: >>>> dev-unsubscribe@tapestry.**apache.org >>>> For additional commands, e-mail: dev-h...@tapestry.apache.org >>> >>> --**--**- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@tapestry.**apache.org >>> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> -- >> Thiago H. de Paula Figueiredo >> >> --**--**- >> To unsubscribe, e-mail: >> dev-unsubscribe@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 - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [jira] [Created] (TAP5-2187) CSS relative URL rewriting isn't lenient enough
Yes it does. It says that .png file was not found, but the exception is while loading the .css file. There are lots of .css files that have errors / missing files in them, not under my control. If I had to write a RequestFilter for each and every one of them, it would be nightmare. The new 5.4 CSS URL rewriting mechanism should just leave the links to unknown assets alone, that's what I mean by 'ignoring' it. Just like the browser does when it loads CSS files. On Sep 23, 2013, at 3:13 PM, Thiago H de Paula Figueiredo wrote: > Hi, Lenny! > > Have you checked if Tapestry throws any exceptions? After all, this is an > HTTP 500, which means internal error. > > I don't know why you mean by "ignore". Did you mean raise a 404 error? > > A workaround would be to add a RequestFilter or Dispatcher that checks for > that non-existent URL and do something about it. > > On Sun, 22 Sep 2013 22:41:02 -0300, Lenny Primak (JIRA) > wrote: > >> Lenny Primak created TAP5-2187: >> -- >> >> Summary: CSS relative URL rewriting isn't lenient enough >> Key: TAP5-2187 >> URL: https://issues.apache.org/jira/browse/TAP5-2187 >> Project: Tapestry 5 >> Issue Type: Bug >> Components: tapestry-core >>Affects Versions: 5.4 >>Reporter: Lenny Primak >> >> >> I am trying to integrate an existing GWT framework as tapestry components. >> One of the .css files its trying to load references an non-existent .png >> file. >> Instead of just ignoring it, Tapestry produces a 500 error loading the .css >> file, >> which I don't believe there is a workaround for. >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira > > > -- > Thiago H. de Paula Figueiredo > > - > 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: [jira] [Created] (TAP5-2187) CSS relative URL rewriting isn't lenient enough
On Sep 23, 2013, at 3:26 PM, Thiago H de Paula Figueiredo wrote: > On Mon, 23 Sep 2013 16:19:14 -0300, Lenny Primak > wrote: > >> Yes it does. It says that .png file was not found, >> but the exception is while loading the .css file. > > Weird. It does sound like a bug. > >> There are lots of .css files that have errors / missing files in them, not >> under my control. >> If I had to write a RequestFilter for each and every one of them, it would >> be nightmare. > > If there was some pattern, you could use the same RequestFilter for all them. The issue is I don't know which one is valid or not, etc. This isn't the way to solve this (see below) > >> The new 5.4 CSS URL rewriting mechanism should just leave the links to >> unknown assets alone, >> that's what I mean by 'ignoring' it. Just like the browser does when it >> loads CSS files. > > You imply the CSS URL rewriting checks whether referenced files exist or not. > Have you checked this is correct? I'm not sure and I haven't checked yet. Yes. Now you understand the core issue. It checks all the references (and tries to rewrite them with checksums) which is correct. If a reference doesn't exist, the whole CSS file gets a 500 server error / exception. This is the issue, because now the whole CSS file is invalid when Tapestry should just ignore missing references and leave them as they are >> >> On Sep 23, 2013, at 3:13 PM, Thiago H de Paula Figueiredo wrote: >> >>> Hi, Lenny! >>> >>> Have you checked if Tapestry throws any exceptions? After all, this is an >>> HTTP 500, which means internal error. >>> >>> I don't know why you mean by "ignore". Did you mean raise a 404 error? >>> >>> A workaround would be to add a RequestFilter or Dispatcher that checks for >>> that non-existent URL and do something about it. >>> >>> On Sun, 22 Sep 2013 22:41:02 -0300, Lenny Primak (JIRA) >>> wrote: >>> >>>> Lenny Primak created TAP5-2187: >>>> -- >>>> >>>> Summary: CSS relative URL rewriting isn't lenient enough >>>>Key: TAP5-2187 >>>>URL: https://issues.apache.org/jira/browse/TAP5-2187 >>>>Project: Tapestry 5 >>>> Issue Type: Bug >>>> Components: tapestry-core >>>> Affects Versions: 5.4 >>>> Reporter: Lenny Primak >>>> >>>> >>>> I am trying to integrate an existing GWT framework as tapestry components. >>>> One of the .css files its trying to load references an non-existent .png >>>> file. >>>> Instead of just ignoring it, Tapestry produces a 500 error loading the >>>> .css file, >>>> which I don't believe there is a workaround for. >>>> >>>> -- >>>> This message is automatically generated by JIRA. >>>> If you think it was sent incorrectly, please contact your JIRA >>>> administrators >>>> For more information on JIRA, see: http://www.atlassian.com/software/jira >>> >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> >>> - >>> 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 >> > > > -- > Thiago H. de Paula Figueiredo > > - > 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: What are the chances of date picker being fixed / upgraded for T5.4?
Speaking of that, what's the status of tapestry-bootstrap and T5.4?
And also is it in maven central yet?
On Sep 18, 2013, at 7:53 PM, Barry Books wrote:
> I was planing on using modernizr to detect if type="date" is supported.
> I've also added min and max to the mixin since they are also supported by
> HTML5. I'm sure I'll put in my Bootstrap library and I'll submit it for
> inclusion in 5.4 but it's not at all compatible with the old DateField.
>
>
>
>
> On Wed, Sep 18, 2013 at 7:12 PM, Geoff Callender <
> geoff.callender.jumpst...@gmail.com> wrote:
>
>> iDevices have their own, great, touch-friendly, date picker for HTML5
>> type="date", so maybe what's needed is to detect the media type before
>> deciding whether to display a JavaScript datepicker.
>>
>> Similarly, recent releases of Chrome handle type="date" with a pretty good
>> picker, so maybe what's needed is a parameter to declare which browsers to
>> NOT override with our picker.
>>
>>
>>
>> On 19 September 2013 08:24, Barry Books wrote:
>>
>>> I started working on this today. Give the HTML5 spec supporting
>> type="date"
>>> I decided to break this into two parts. First I wrote a Translator for
>> the
>>> Date class. This means you can now just use TextField for dates if the
>>> input type is Date. Since the Translator is contributed in the AppModule
>>> you get a consistent date format across all fields. If you want to a
>>> different format you can just supply a different translator to the
>>> textField. Next I'll just create a mixin that adds some javascript to the
>>> field. I suspect I'll just use the jQueryUI one but it should be easy to
>>> swap them since it's a mixin. I'm not sure how general this approach is
>> but
>>> it solves all my problems.
>>>
>>> FYI: It would be possible to create the Translator on the fly in the
>> mixin
>>> except for two problems.
>>> 1. The Translator has a default which means the mixin cannot do a
>>> BindParameter and set the value
>>> 2. I don't get a form prepare event so I can't set the translator on the
>>> form submit.
>>>
>>> The Translator is here:
>>>
>>> public class DateTranslator extends AbstractTranslator {
>>>
>>>
>>>
>>>private final String formatString;
>>>
>>>
>>>
>>>public DateTranslator(String format) {
>>>
>>>super("DateTranslator(" +
>>> format + ")",Date.class,"date");
>>>
>>>formatString = format;
>>>
>>>}
>>>
>>>
>>>
>>>@Override
>>>
>>>public String toClient(Date value) {
>>>
>>>return new
>>> SimpleDateFormat(formatString).format(value);
>>>
>>>}
>>>
>>>
>>>
>>>@Override
>>>
>>>public Date parseClient(Field field,
>> String
>>> clientValue, String message)
>>>
>>>throws
>>> ValidationException {
>>>
>>>
>>>
>>>ParsePosition
>> parsePosition
>>> = new ParsePosition(0);
>>>
>>>DateFormat format = new
>>> SimpleDateFormat(formatString);
>>>
>>> format.setLenient(false);
>>>
>>>
>>>
>>>Date date =
>>> format.parse(clientValue,parsePosition);
>>>
>>>if ( parsePosition.getIndex() !=
>>> clientValue.length() ) {
>>>
>>>throw new
>>> ValidationException(message);
>>>
>>>}
>>>
>>>return date;
>>>
>>>}
>>>
>>>
Re: [jira] [Commented] (TAP5-2169) Core stack is not included by default
Technically I agree but it breaks compatibility. So I reluctantly disagree. On Sep 18, 2013, at 7:39 PM, Geoff Callender wrote: > What changed? The JIRA issue says "fixed" but there's no info about how. > > IMHO, it was a FABULOUS decision to emit minimal css classes and NO > stylesheet. Developers are free to add the core stack if they wish and free > to add refining css classes to the tml. > > Who agrees/disagreees? > > > On 12 September 2013 11:57, Hudson (JIRA) wrote: > >> >>[ >> https://issues.apache.org/jira/browse/TAP5-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13765081#comment-13765081] >> >> Hudson commented on TAP5-2169: >> -- >> >> SUCCESS: Integrated in tapestry-trunk-freestyle #1159 (See [ >> https://builds.apache.org/job/tapestry-trunk-freestyle/1159/]) >> TAP5-2169: Always import the core stack (hlship: rev >> ec83d78d77c7dfde8688dd1f4db351414f42be7f) >> * 54_RELEASE_NOTES.md >> * >> tapestry-core/src/main/java/org/apache/tapestry5/modules/TapestryModule.java >> >> >>> Core stack is not included by default >>> - >>> >>>Key: TAP5-2169 >>>URL: https://issues.apache.org/jira/browse/TAP5-2169 >>>Project: Tapestry 5 >>> Issue Type: Bug >>> Components: tapestry-core >>> Affects Versions: 5.4 >>> Reporter: Lenny Primak >>> Assignee: Howard M. Lewis Ship >>> Priority: Minor >>>Fix For: 5.4 >>> >>> >>> For simple applications, "core" stack is not included, which breaks the >> UI, >>> because bootstrap.css and other assets are not loaded. >>> I think "core" stack should be forced to be included (possibly >> optionally turned off by config) >>> but it should be included by default >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: What are the chances of date picker being fixed / upgraded for T5.4?
Sounds great. Are you going to submit a patch to tapestry?
If not, Consider contributing this to FlowLogix. You already a committer there.
> On Sep 18, 2013, at 5:24 PM, Barry Books wrote:
>
> I started working on this today. Give the HTML5 spec supporting type="date"
> I decided to break this into two parts. First I wrote a Translator for the
> Date class. This means you can now just use TextField for dates if the
> input type is Date. Since the Translator is contributed in the AppModule
> you get a consistent date format across all fields. If you want to a
> different format you can just supply a different translator to the
> textField. Next I'll just create a mixin that adds some javascript to the
> field. I suspect I'll just use the jQueryUI one but it should be easy to
> swap them since it's a mixin. I'm not sure how general this approach is but
> it solves all my problems.
>
> FYI: It would be possible to create the Translator on the fly in the mixin
> except for two problems.
> 1. The Translator has a default which means the mixin cannot do a
> BindParameter and set the value
> 2. I don't get a form prepare event so I can't set the translator on the
> form submit.
>
> The Translator is here:
>
> public class DateTranslator extends AbstractTranslator {
>
>
>
>private final String formatString;
>
>
>
>public DateTranslator(String format) {
>
>super("DateTranslator(" +
> format + ")",Date.class,"date");
>
>formatString = format;
>
>}
>
>
>
>@Override
>
>public String toClient(Date value) {
>
>return new
> SimpleDateFormat(formatString).format(value);
>
>}
>
>
>
>@Override
>
>public Date parseClient(Field field, String
> clientValue, String message)
>
>throws
> ValidationException {
>
>
>
>ParsePosition parsePosition
> = new ParsePosition(0);
>
>DateFormat format = new
> SimpleDateFormat(formatString);
>
>format.setLenient(false);
>
>
>
>Date date =
> format.parse(clientValue,parsePosition);
>
>if ( parsePosition.getIndex() !=
> clientValue.length() ) {
>
>throw new
> ValidationException(message);
>
>}
>
>return date;
>
>}
>
>
>
>@Override
>
>public void render(Field field, String
> message, MarkupWriter writer, FormSupport formSupport) {
>
>
> writer.attributes("data-format",formatString);
>
>}
>
>
>
> }
>
>
> On Tue, Sep 17, 2013 at 11:25 PM, Lenny Primak wrote:
>
>> Agreed. I will let the dev list know when I will start working on
>> datepicker.
>> Barry, if you start earlier let me know and we can coordinate efforts. I
>> don't want to duplicate efforts. I have never written PropertyEditBlocks
>> etc so you may be in a better position to do this.
>>
>> What I don't want to do is try to write my own datepicker. We should use
>> one of the public ally available ones, I,e, bootstrap of jquery UI one.
>>
>>> On Sep 17, 2013, at 10:09 PM, Barry Books wrote:
>>>
>>> This is high on my list also. I've spent today looking at datepickers and
>>> concluded none of them are perfect and it may be best to just implement
>> the
>>> one you want and not bother with the Tapestry one. However I do think
>>> the TypeCoercer
>>> for String to DateFormat needs to be fixed. The current one does not do
>>> setLenient(false) which I think is needed no matter what data picker is
>>> used and while most Tapestry configuration can be overridden this one
>>> cannot. I'll submit a JIRA for this. The fix is easy and even makes the
>>> current datepicker better. Here is a description of setLenient:
>>>
>>>
Re: What are the chances of date picker being fixed / upgraded for T5.4?
Agreed. I will let the dev list know when I will start working on datepicker. Barry, if you start earlier let me know and we can coordinate efforts. I don't want to duplicate efforts. I have never written PropertyEditBlocks etc so you may be in a better position to do this. What I don't want to do is try to write my own datepicker. We should use one of the public ally available ones, I,e, bootstrap of jquery UI one. On Sep 17, 2013, at 10:09 PM, Barry Books wrote: > This is high on my list also. I've spent today looking at datepickers and > concluded none of them are perfect and it may be best to just implement the > one you want and not bother with the Tapestry one. However I do think > the TypeCoercer > for String to DateFormat needs to be fixed. The current one does not do > setLenient(false) which I think is needed no matter what data picker is > used and while most Tapestry configuration can be overridden this one > cannot. I'll submit a JIRA for this. The fix is easy and even makes the > current datepicker better. Here is a description of setLenient: > > Specify whether or not date/time parsing is to be lenient. With lenient > parsing, the parser may use heuristics to interpret inputs that do not > precisely match this object's format. With strict parsing, inputs must > match this object's format. > > I don't think you want heuristics when validating dates, you want the > format to precisely match. > > > On Tue, Sep 17, 2013 at 6:04 PM, Lenny Primak wrote: > >> High because we have to get this done for 5.4. Probably start with >> incorporating the new datefield into FlowLogix though. Not sure patch makes >> sense in this case though. But I am willing to work on the datefield >> modernization. >> >> On Sep 16, 2013, at 7:02 PM, Howard Lewis Ship wrote: >> >>> What are the chances of a patch? >>> >>> I'm stretched really, really thin right now. More so than usual. I'm >>> anything but a fan of the built-in DateField component for any number of >>> reasons, but I can't squeeze blood from a stone. >>> >>> >>> On Mon, Sep 16, 2013 at 7:12 PM, Lenny Primak >> wrote: >>> >>>> Just for planning purposes, what are the changes of datepicker being >>>> replaced to bootstrap (or any other modern one) >>>> prior to T5.4 release? >>>> >>>> I need to plan this out, because current T5.4 datepicker is unusable for >>>> us, so if the new datepicker isn't in the cards, >>>> we need to start writing our own datepicker integration. >>>> >>>> Thank you. >>>> >>>> >>>> >>>> - >>>> 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 >> >> - >> 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: What are the chances of date picker being fixed / upgraded for T5.4?
High because we have to get this done for 5.4. Probably start with incorporating the new datefield into FlowLogix though. Not sure patch makes sense in this case though. But I am willing to work on the datefield modernization. On Sep 16, 2013, at 7:02 PM, Howard Lewis Ship wrote: > What are the chances of a patch? > > I'm stretched really, really thin right now. More so than usual. I'm > anything but a fan of the built-in DateField component for any number of > reasons, but I can't squeeze blood from a stone. > > > On Mon, Sep 16, 2013 at 7:12 PM, Lenny Primak wrote: > >> Just for planning purposes, what are the changes of datepicker being >> replaced to bootstrap (or any other modern one) >> prior to T5.4 release? >> >> I need to plan this out, because current T5.4 datepicker is unusable for >> us, so if the new datepicker isn't in the cards, >> we need to start writing our own datepicker integration. >> >> Thank you. >> >> >> >> - >> 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 - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
What are the chances of date picker being fixed / upgraded for T5.4?
Just for planning purposes, what are the changes of datepicker being replaced to bootstrap (or any other modern one) prior to T5.4 release? I need to plan this out, because current T5.4 datepicker is unusable for us, so if the new datepicker isn't in the cards, we need to start writing our own datepicker integration. Thank you. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [5.4] Problems with the asset checksums and relative paths based on them
JIRA created: https://issues.apache.org/jira/browse/TAP5-2185 On Sep 16, 2013, at 8:47 AM, Thiago H de Paula Figueiredo wrote: > On Mon, 16 Sep 2013 01:00:20 -0300, Lenny Primak > wrote: > >> Is there a JIRA for this? > > I don't think so. > >> I would like to watch the resolution for this, as this is hitting me with >> the GWT / SmartGWT integration > > While a permanent solution isn't provided in Tapestry itself, you can adapt > the one I wrote for tapestry-wymeditor: > https://github.com/thiagohp/tapestry-wymeditor/blob/master/src/main/java/br/com/arsmachina/tapestry_wymeditor/services/WymeditorRequestFilter.java. > > -- > Thiago H. de Paula Figueiredo > > - > 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
[5.4] Problems with the asset checksums and relative paths based on them
Is there a JIRA for this? I would like to watch the resolution for this, as this is hitting me with the GWT / SmartGWT integration - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [T5.4] Critical but in beanvalidator
Very good. Thanks. On Sep 9, 2013, at 11:45 AM, "Thiago H de Paula Figueiredo" wrote: > There are two other tickets posted about the same issue, one of them mine, so > I marked yours and mine as duplicates (the other one is older than ours). > > On Fri, 06 Sep 2013 21:23:12 -0300, Lenny Primak > wrote: > >> Yes, I meant bug, not but :) >> >> On Sep 6, 2013, at 8:21 PM, Lenny Primak wrote: >> >>> https://issues.apache.org/jira/browse/TAP5-2175 >>> >>> If @Size(min) is not specified, but @Size(max) is, the validation will fail >>> with correct input >>> >>> >>> - >>> 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 > > > -- > Thiago H. de Paula Figueiredo > > - > 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: [T5.4] Critical but in beanvalidator
Yes, I meant bug, not but :) On Sep 6, 2013, at 8:21 PM, Lenny Primak wrote: > https://issues.apache.org/jira/browse/TAP5-2175 > > If @Size(min) is not specified, but @Size(max) is, the validation will fail > with correct input > > > - > 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
[T5.4] Critical but in beanvalidator
https://issues.apache.org/jira/browse/TAP5-2175 If @Size(min) is not specified, but @Size(max) is, the validation will fail with correct input - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Status of TAP5-1973
The app lives in multiple environments. Some in the cloud, some in a private cloud, depending on a customer site. There are multiple clusters (not one cluster with multiple nodes) that are dynamically created (departments, etc.) and ports are being automatically assigned by the admin interface in some instances. This works very well for us, and both devs and ops love this system. In any case, this is clearly a bug and should be fixed without requiring developers to specify ports to Tapestry that are already known by the system. On Sep 3, 2013, at 1:26 PM, Dmitry Gusev wrote: > Lenny, what cloud / cluster environments are you talking about? Do you have > any concrete examples? > I'm using this feature with OpenShift and Jelastic and it works fine, > there's no any dynamically assigned ports. > Is this even can be possible? > Because as far as I know application servers require so their binding ports > have to be set implicitly in configs. > Or these ports can be set using app-server specific system variables, which > you may read in provideApplicationDefaults and set those as value for the > tapestry symbols. > > > On Tue, Sep 3, 2013 at 8:53 PM, Lenny Primak wrote: > >> Indeed it does (as stated in the comments of the issue also) >> Setting them is not a good option, as the installation is in the cloud / >> clusters >> with multiple ports, dynamically assigned ports, etc. >> Setting these would be a maintenance nightmare (if even possible) >> >> On Sep 3, 2013, at 9:20 AM, Massimo Lusetti wrote: >> >>> On Tue, Sep 3, 2013 at 10:22 AM, Lenny Primak >> wrote: >>> >>>> In this issue: https://issues.apache.org/jira/browse/TAP5-1973 >>>> >>>> If you take a look at the last comment from Alejandro Scandroli, >>>> it looks like the side effect is still not fixed in 5.4. >>>> Right now, this is being worked around in FlowLogix, but I would like to >>>> remove >>>> this code (i.e. asking for this bug to get fixed) in 5.4 >>>> >>>> Thank you >>>> >>>> >>> Does the "issue" pops out only if you don't set HOSTPORT and >>> HOSTPORT_SECURE ? >>> >>> -- >>> Massimo Lusetti >> >> >> - >> 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: Status of TAP5-1973
What you are saying is correct and that is indeed the case (dynamic configuration) I am not focusing on my use case alone, but my use case does expose this bug. The way the code is right now is incorrect. This is not just reported by me but by at least Alejandro as well. There is a test as well in the comments. On Sep 3, 2013, at 1:42 PM, Kalle Korhonen wrote: > On Tue, Sep 3, 2013 at 10:33 AM, Lenny Primak wrote: > >> In any case, this is clearly a bug and should be fixed without requiring >> developers >> to specify ports to Tapestry that are already known by the system. >> > > Don't focus on your use case alone. There are too many ways to set up the > routing, which is why it's best to explicitly set the hostname and ports > yourself. If your app lives in multiple environment, don't try to make the > app contain these settings but set them in an external configuration. > > Kalle > > > >> >> On Sep 3, 2013, at 1:26 PM, Dmitry Gusev wrote: >> >>> Lenny, what cloud / cluster environments are you talking about? Do you >> have >>> any concrete examples? >>> I'm using this feature with OpenShift and Jelastic and it works fine, >>> there's no any dynamically assigned ports. >>> Is this even can be possible? >>> Because as far as I know application servers require so their binding >> ports >>> have to be set implicitly in configs. >>> Or these ports can be set using app-server specific system variables, >> which >>> you may read in provideApplicationDefaults and set those as value for the >>> tapestry symbols. >>> >>> >>> On Tue, Sep 3, 2013 at 8:53 PM, Lenny Primak >> wrote: >>> >>>> Indeed it does (as stated in the comments of the issue also) >>>> Setting them is not a good option, as the installation is in the cloud / >>>> clusters >>>> with multiple ports, dynamically assigned ports, etc. >>>> Setting these would be a maintenance nightmare (if even possible) >>>> >>>> On Sep 3, 2013, at 9:20 AM, Massimo Lusetti wrote: >>>> >>>>> On Tue, Sep 3, 2013 at 10:22 AM, Lenny Primak >>>> wrote: >>>>> >>>>>> In this issue: https://issues.apache.org/jira/browse/TAP5-1973 >>>>>> >>>>>> If you take a look at the last comment from Alejandro Scandroli, >>>>>> it looks like the side effect is still not fixed in 5.4. >>>>>> Right now, this is being worked around in FlowLogix, but I would like >> to >>>>>> remove >>>>>> this code (i.e. asking for this bug to get fixed) in 5.4 >>>>>> >>>>>> Thank you >>>>>> >>>>>> >>>>> Does the "issue" pops out only if you don't set HOSTPORT and >>>>> HOSTPORT_SECURE ? >>>>> >>>>> -- >>>>> Massimo Lusetti >>>> >>>> >>>> - >>>> 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 >> >> - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Status of TAP5-1973
Indeed it does (as stated in the comments of the issue also) Setting them is not a good option, as the installation is in the cloud / clusters with multiple ports, dynamically assigned ports, etc. Setting these would be a maintenance nightmare (if even possible) On Sep 3, 2013, at 9:20 AM, Massimo Lusetti wrote: > On Tue, Sep 3, 2013 at 10:22 AM, Lenny Primak wrote: > >> In this issue: https://issues.apache.org/jira/browse/TAP5-1973 >> >> If you take a look at the last comment from Alejandro Scandroli, >> it looks like the side effect is still not fixed in 5.4. >> Right now, this is being worked around in FlowLogix, but I would like to >> remove >> this code (i.e. asking for this bug to get fixed) in 5.4 >> >> Thank you >> >> > Does the "issue" pops out only if you don't set HOSTPORT and > HOSTPORT_SECURE ? > > -- > Massimo Lusetti - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Status of TAP5-1973
Thank you Kalle. I think its best to have this configurable, only optionally enable this behavior. On Sep 3, 2013, at 12:37 PM, Kalle Korhonen wrote: > Hairy. The best is always to explicitly set the ports yourself as it > applies to your application. Regardless, I'm thinking of re-opening this > since the current seems more wrong than the old way. > > Kalle > > > On Tue, Sep 3, 2013 at 6:20 AM, Massimo Lusetti wrote: > >> On Tue, Sep 3, 2013 at 10:22 AM, Lenny Primak >> wrote: >> >>> In this issue: https://issues.apache.org/jira/browse/TAP5-1973 >>> >>> If you take a look at the last comment from Alejandro Scandroli, >>> it looks like the side effect is still not fixed in 5.4. >>> Right now, this is being worked around in FlowLogix, but I would like to >>> remove >>> this code (i.e. asking for this bug to get fixed) in 5.4 >>> >>> Thank you >>> >>> >> Does the "issue" pops out only if you don't set HOSTPORT and >> HOSTPORT_SECURE ? >> >> -- >> Massimo Lusetti >> - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Status of TAP5-1973
In this issue: https://issues.apache.org/jira/browse/TAP5-1973 If you take a look at the last comment from Alejandro Scandroli, it looks like the side effect is still not fixed in 5.4. Right now, this is being worked around in FlowLogix, but I would like to remove this code (i.e. asking for this bug to get fixed) in 5.4 Thank you - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Transactions and AfterCommit
John, have you really, actually looked at the state of JEE these days? It's trivial to set up, trivial to develop in, and IMHO, easier to learn than many other things in Java. Yes, the "old pre-JEE5 days were bad" but JEE 5,6,7 are a whole different animal. You can get it up and running in less than 10 minutes (Glassfish) and it's much easier than trying to cobble up the same environment from different pieces. Also, we developed a module (FlowLogix) that integrates most things JEE with Tapestry and Shiro. I have seen this again and again, my customers have the perception of "JEE bad/complicated" and spending at least 5x the time trying to cobble up an environment that tries (unsuccessfully) to replicate what JEE is doing. On Aug 27, 2013, at 3:49 AM, John wrote: > I'm reluctant to move my small/medium sized pure Tapestry project into a JEE > environment even though I am updating accross multiple databases and have > non-trivial needs for transactions. I don't see sufficient justifcation to > use JEE unless there is substantial need of EJBs. > > So far I have got away with using CommitAfter and some more manual coding to > handle the transactions. The main reason CommitAfter sucks IMO is because it > is coded on the interface and so breaks the rule about hiding implementation. > For that reason alone IMO it needs to be addressed. > > If I do decide to go into XA I will use Bitronix or similar over JEE and code > my transactions manually in the implementing classes, unless more demand for > EJB arises. > > John > > > - Original Message - > From: Taha Hafeez Siddiqi > To: Tapestry development > Sent: Sunday, August 25, 2013 1:17 AM > Subject: Re: Transactions and AfterCommit > > > I have used spring and JEE in the past and I don't think every project needs > them. The transaction support comes with a lot-n-lots of dependencies (at > least at that time it was the case :)) and some people don't like it. > > All we need is a support for @Transactional->Required /readonly. I think if > we support them, most of common requirements are met. > > regards > Taha > > On 25-Aug-2013, at 4:18 AM, Lenny Primak wrote: > >> I would leave everything as is now. >> Tapestry should not try to implement or re-implement full transaction >> support. >> This has already been done with JEE or spring. If a user wants this support, >> they should just use what already exists out there. >> >> >> On Aug 24, 2013, at 3:18 PM, "Thiago H de Paula Figueiredo" >> wrote: >> >>> On Sat, 24 Aug 2013 09:39:11 -0300, Taha Siddiqi >>> wrote: >>> >>>> Hi everyone >>> >>> Hi! >>> >>>> There are two @CommitAfters and both work differently from each other. >>> >>> This is a problem >>> >>> Here's my suggestion: >>> >>> 1) Leave the @CommitAfter implementations the way they are now for >>> backward-compatibility reasons. >>> 2) Mark them as deprecated. >>> 3) Use EJB's @TransactionAttribute annotation instead of tapestry-hibernate >>> and tapestry-jpa defining different annotations. >>> 4) Implement the different transaction attribute types described in >>> http://docs.oracle.com/cd/B32110_01/web.1013/b28221/servtran002.htm. >>> >>> Question: use JTA? I don't know. >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> >>> - >>> 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: Transactions and AfterCommit
I would leave everything as is now. Tapestry should not try to implement or re-implement full transaction support. This has already been done with JEE or spring. If a user wants this support, they should just use what already exists out there. On Aug 24, 2013, at 3:18 PM, "Thiago H de Paula Figueiredo" wrote: > On Sat, 24 Aug 2013 09:39:11 -0300, Taha Siddiqi > wrote: > >> Hi everyone > > Hi! > >> There are two @CommitAfters and both work differently from each other. > > This is a problem > > Here's my suggestion: > > 1) Leave the @CommitAfter implementations the way they are now for > backward-compatibility reasons. > 2) Mark them as deprecated. > 3) Use EJB's @TransactionAttribute annotation instead of tapestry-hibernate > and tapestry-jpa defining different annotations. > 4) Implement the different transaction attribute types described in > http://docs.oracle.com/cd/B32110_01/web.1013/b28221/servtran002.htm. > > Question: use JTA? I don't know. > > -- > Thiago H. de Paula Figueiredo > > - > 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: Final call for TAP5-2070
Already voted :) On Jul 31, 2013, at 12:30 PM, Massimo Lusetti wrote: > On Wed, Jul 31, 2013 at 6:52 PM, Lenny Primak wrote: > > As long it's a 404 in both production and development mode I'm fine with >> that. > BTW anyone interested in this could go to the issue page on Jira and vote > for it. > > -- > Massimo Lusetti - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Final call for TAP5-2070
As long it's a 404 in both production and development mode I'm fine with that. On Jul 31, 2013, at 11:42 AM, Massimo Lusetti wrote: > On Wed, Jul 31, 2013 at 6:31 PM, Lance Java wrote: > > You can have your cake and eat it! >> >> It's valid for a 404 response to have a body and a content type. >> > > Fine, let's put it this way: In dev mode is valuable to have and > "explanation" of what happened while in prod mod simply a 404 so it could > be caught by the servlet error dispatcher, the one configured in web.xml ? > > -- > Massimo Lusetti - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Final call for TAP5-2070
As I see its not the same at all. The exception report behavior is the same only the text is different. Here you are proposing completely different error and behavior in production and in development. Intent is not the same. What if someone intercepts all exceptions and emails production support? Other custom behavior would all be broken. On Jul 31, 2013, at 11:07 AM, Massimo Lusetti wrote: > On Wed, Jul 31, 2013 at 6:00 PM, Lenny Primak wrote: > > I would say no. >> The behavior in production.and development mode differences in general is >> a bad idea. This will preclude valid testing in development. > It would be the same situation of the ExceptionReport page and it would go > hand to hand with the excellent feedback given by the whole framework, > let's read this way: "Hey dev you're accessing page X which doesn't declare > an activation context Y so this is considered an error and will result in a > 404 within production" > > -- > Massimo Lusetti - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Final call for TAP5-2070
I would say no.
The behavior in production.and development mode differences in general is a bad
idea. This will preclude valid testing in development.
On Jul 31, 2013, at 10:51 AM, Howard Lewis Ship wrote:
> Could this be a case where we want one behavior in development (a Tapestry
> error) and another in production (a 404 status)?
>
>
> On Wed, Jul 31, 2013 at 8:38 AM, Dimitris Zenios
> wrote:
>
>> +1
>>
>>
>> On Wed, Jul 31, 2013 at 6:21 PM, Lenny Primak >> wrote:
>>
>>> Big +1 for me. I currently use the following code in the index page to
>>> work around this issue:
>>>
>>> 8 /**
>>> 9* Restore 404 Not Found errors
>>> 10 * @param context
>>> 11 * @return
>>> 12 */
>>> 13 HttpError onActivate(EventContext context)
>>> 14 {
>>> 15 if (context.getCount() == 0)
>>> 16 {
>>> 17 return null;
>>> 18 }
>>> 19
>>> 20 return new HttpError(404, "Resource not found.");
>>> 21 }
>>>
>>>
>>> On Jul 31, 2013, at 10:14 AM, Massimo Lusetti
>> wrote:
>>>
>>>> Hi devs,
>>>> I would like to have
>>>> https://issues.apache.org/jira/browse/TAP5-2070closed before 5.4 will
>>>> go to beta stage.
>>>>
>>>> I mainly want to decide if the current behavior is acceptable for the
>>>> majority or we need to change it, then we can discuss on the
>>> implementation.
>>>>
>>>> Please comment.
>>>>
>>>> --
>>>> Massimo Lusetti
>
>
>
> --
> 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: Final call for TAP5-2070
Big +1 for me. I currently use the following code in the index page to work
around this issue:
8 /**
9* Restore 404 Not Found errors
10 * @param context
11 * @return
12 */
13 HttpError onActivate(EventContext context)
14 {
15 if (context.getCount() == 0)
16 {
17 return null;
18 }
19
20 return new HttpError(404, "Resource not found.");
21 }
On Jul 31, 2013, at 10:14 AM, Massimo Lusetti wrote:
> Hi devs,
> I would like to have
> https://issues.apache.org/jira/browse/TAP5-2070closed before 5.4 will
> go to beta stage.
>
> I mainly want to decide if the current behavior is acceptable for the
> majority or we need to change it, then we can discuss on the implementation.
>
> Please comment.
>
> --
> Massimo Lusetti
Re: Discussion: Future of tapestry-test & friends.
I have never been able to get any selenium tapestry tests to run on my Mac at all BTW. Something has to do with firefiox version or something. So, even the proverbial 'patch with tests' isn't possible for me. I really don't mind the bleeding edge technology though. On Jul 31, 2013, at 9:10 AM, Ulrich Stärk wrote: > One reason I haven't contributed much in terms of code for quite some time is > the ever changing > technology stack Tapestry is built with. We have an increasingly complex > stack of bleeding-edge > tools and technologies that I simply lack the time of keeping up with. > > I have the feeling that this might be a turn-down for other potential > contributors as well. I won't > be against it but don't be surprised about continously declining contributor > activity. > > Uli > > > On 30.07.2013 23:50, Howard Lewis Ship wrote: >> One thing I've been saying in some of the bugs I've been closing is my >> desire to get out of the testing side of things. I have no desire to >> maintain the existing TestNG, EasyMock, and Selenium support code ... you >> may have noticed that I'm a fan of Spock for unit and mock testing, and Geb >> for end-to-end integration testing. >> >> I'd love to scrap the existing tapestry-core tests and rewrite for Spock >> and Geb, but (alas), that is a huge effort. But I would like to start >> documenting in release notes and elsewhere that the path forward is to >> invest in Spock and Geb. >> >> Ok ... as usual, since I've been thinking about this in the background for >> too long, my invitation to discuss sounds like a mandate ... but, >> seriously, thoughts on this subject? > > > - > 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: Copy annotations from servce implementation to proxies
I think you want Tapestry's very light JPA implementation to do way more than what it was meant to do originally. Your requirements clearly require JEE or equivalent infrastructure. You should use it. On Jul 4, 2013, at 4:04 AM, John wrote: > This is a real world issue for me. > > I recently implemented 2 version of an auditing service, one which used log4j > to persist and another that used a db. When I created the later db version I > added the CommitAfter annotations to the service interface making the change > a little messy and not entirely suitable for the prior log4j implementation. > > It would seem to make more sense for the CommitAfter and PersistenceContext > annotations to be in the implementing class. Maybe you can do this anyway - I > can't remember if I checked this or not, but I think I did and it doesn't > work that way. > > John > - Original Message - > From: Thiago H de Paula Figueiredo > To: Tapestry development > Sent: Friday, June 28, 2013 2:27 PM > Subject: Copy annotations from servce implementation to proxies > > > On Thu, 27 Jun 2013 06:05:14 -0300, wrote: > >> Hello, >> John has commented on >> http://tapestry.apache.org/integrating-with-jpa.html. >> You can find the comment here: >> http://tapestry.apache.org/integrating-with-jpa.html#comment_1410 >> Please note that if the comment contains a hyperlink, it must be approved >> before it is shown on the site. >> >> Below is the reply that was posted: >> >> Adding implementations specific annotations to the service interfaces >> breaks the interface/implementation independence. >> > > I agree with this. What do you guys think? I think this is a serious > shotcoming in Tapestry-IoC. > > -- > Thiago H. de Paula Figueiredo > > - > 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] Lance Semmens as a committer
Lenny Primak: +1 (non-binding) On Jul 3, 2013, at 12:43 PM, Kalle Korhonen wrote: > Kalle Korhonen: +1 (non-binding) - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: jQuery 2.x or stick with 1.x?
Same here. Big -1 for dropping older IE support. +1 for jq2 if we can keep older IE.support. On May 27, 2013, at 7:21 AM, Barry Books wrote: >> From the jQuery 2.0 release notes: > > As promised, this version leaves behind the older Internet Explorer 6, 7, >> and 8 browsers. In return it is smaller, faster, and can be used in >> JavaScript environments where the code needed for old-IE compatibility >> often causes problems of its own. *But don’t worry, the jQuery team still >> supports the 1.x branch which does run on IE 6/7/8.* You can (and should) >> continue to use jQuery 1.9 (and the upcoming 1.10) on web sites that need >> to accommodate older browsers. > > > I use Tapestry to build sites for business/government that are still using > Windows XP and are therefore stuck on IE8. Bootstrap 3.X appears it will > support IE8. I can see why people would rather drop older IE support but at > this point I don't think it's practical if you want your product to be used > in a business/government environment. > > So I would say if it's easy to pick (or Dmitry's suggestion) I'm OK with > that but if it you are talking about dropping IE8 support I would have to > say a *BIG* -1. > > Barry > > > > > On Mon, May 27, 2013 at 12:59 AM, Kristian Marinkovic < > kristian.marinko...@gmail.com> wrote: > >> +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 >> - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: T5.3.7 release anyone?
How about this one? https://issues.apache.org/jira/browse/TAP5-2014 On Apr 1, 2013, at 1:38 PM, Kalle Korhonen wrote: > Thanks Bob, Massimo. At least > https://issues.apache.org/jira/browse/TAP5-2097 and > https://issues.apache.org/jira/browse/TAP5-1890 merge to T5.3 for me, and > need to check if there was anything else. I can get them done this week. > > Kalle > > > On Mon, Apr 1, 2013 at 12:27 AM, Massimo Lusetti wrote: > >> I agree. Some minor fixes are in 5.3 branch and not release (if memory >> serve) so a release would be nice. >> >> We could plan a release asap, Kalle what's left for you? Others? >> >> Cheers >> >> >> On Sun, Mar 31, 2013 at 1:26 PM, Bob Harner wrote: >> >>> I do think a 5.3.7 release would be worthwhile. It seems to me that >>> 5.4 needs a bit more shaking out (and documenting) before it is ready >>> for release. Also, it has been almost 6 months since 5.3.6 was >>> released, and until then we were producing a release about every 2 >>> months on average. >>> >>> On Sun, Mar 31, 2013 at 2:17 AM, Kalle Korhonen >>> wrote: Is anybody in need of T5.3.7? I'm not quite ready myself just yet but >>> there are a few relevant fixes for us and I could put a few more in. Is >> anybody else looking for a 5.3.7 release? Massimo, I think you've done the last 5.3.x releases. How's your experience been regarding the release >> process? Is everything documented, any gotchas, pain points etc? Or would you perhaps be willing to cut one more release yourself? Kalle >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> >> -- >> Massimo >> http://meridio.blogspot.com >>
Re: Coming soon: per-Asset checkums in URLs
I agree with that. Makes it very, very fast On Mar 12, 2013, at 6:31 AM, Bob Harner wrote: > As a Tapestry user, I agree with your preference to prevent asset > requests entirely rather than go the chattier ETag route. I would > rather give up on the checksums-in-URLs idea (at least for modules) > than have any significant increase in the number of requests to the > server. > > I think Tapestry's far-future expires headers is one of its best features. > > On Mon, Mar 11, 2013 at 4:35 PM, Howard Lewis Ship wrote: >> I've been working, a few hours a week, on getting per-asset checksums into >> URLs. >> >> Some parts of this have been a challenge to accomplish without completely >> breaking the Asset interface and a bunch of public services. >> >> For ordinary assets, it's pretty easy ... but for aggregated JavaScript >> libraries its been a pain that's affected a bunch of stuff. >> >> CSS files are now rewritten, since relative URLs will be broken by the >> addition of the checksum. I have a first (but not final) pass at this, >> where url() patterns in the CSS are converted into complete paths. This >> also opens the door to CSS aggregation as well as JavaScript aggregation. >> >> I still don't have a great solution for JavaScript modules; RequireJS/AMD >> expect that there's a common root folder name (such as "/assets/modules/"), >> and module "a/b" is simply "*root*/a/b.js". For individual modules, you can >> write your own overrides. In fact, Tapestry has to strip off the ".js' >> part (which is hard-wired by RequireJS) because the actual server-side >> resource could be CoffeeScript or some other language that compiles to >> JavaScript. >> >> Short of iterating all server-side module files and writing a RequireJS >> config for each one (mapping each name to a URL with an embedded checksum), >> there isn't a great solution. Alternately, something could iterate all the >> server-side modules and built a composite checksum, but there are at least >> a couple of virtual modules generated at runtime (and locale specific for >> extra kicks). >> >> Modules may have to stay on the 5.3 approach: using the application version >> number for everything. >> >> Finding the sweet spot where assets of all kinds (CSS, JavaScript >> libraries, JavaScript modules, etc.) can be changed freely and the URLs >> automatically reflect the actual content (that is, include a checksum of >> that content) for ideal client-side caching ... may simply be out of reach. >> >> Perhaps for modules we should use an alternate approach based on ETags ( >> http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would not >> need to be any version number of checksum in a module URL, but clients >> would request the module content more often (and based on ETag, would often >> get a 304 Not Modified). I would prefer to see a URL that changes when the >> content changes (which prevents the request entirely). >> >> -- >> 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
Issues relevant to us, maybe take a look at fixing in 5.4?
https://issues.apache.org/jira/browse/TAP5-1799 https://issues.apache.org/jira/browse/TAP5-1779 https://issues.apache.org/jira/browse/TAP5-1973 https://issues.apache.org/jira/browse/TAP5-805 (this may be fixed in 5.4) Thank you very much - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Tapestry 5.4 Java / JS API status
I was wondering if it was too early to start porting FlowLogix to 5.4 If the JS and Java APIs are stable as of now, I'd like to start. Can I get confirmation on any of this? Thanks I also would like to contribute some, if not all of the code. I've been maintaining this for almost 2 years now, and we have significant investment in this ant Tapestry in production, so abandonware should be a non-issue. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: About GSoC 2013 Idea page
Using something like NIO-based frameworks has no value as far as I am concerned. We did a lot of work evaluating NIO-based and general event-based I/O frameworks, and the good old one-thread-per-conncetino blew everything else out of the water performance wise for good load-balanced / clustered setups. On Mar 9, 2013, at 1:32 PM, Mayur Patil wrote: > Hello, > > As GSoC mostly considers projects that will contribute to the codebase. > > I am agree with deployment power of Play framework as it supports duo. > > But what is the benefit and making difference of using Netty?? > > I mean to say people are using and wll use Tomcat ?? > > What's the addon over Tomcat ?? Will you please illustrate that wiil be > > helpful to get insight?? > > And Thanks for the idea !! > > *-- > Cheers, > Mayur* - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: How to handle 404 nicely (TAP5-879)
This wouldn't work in an AJAX request, setupRender() will not get called but onActivate() will On Jan 28, 2013, at 8:49 AM, SlimerDude wrote: >> solution wouldn't handle when there's an onActivate() >> method without parameters just used for initialization stuff > > If an onActivate() doesn't use a context / take any params, then the code > could be moved to setupRender(). > > > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/How-to-handle-404-nicely-TAP5-879-tp5719588p5719614.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: How to handle 404 nicely (TAP5-879)
This is what I do in my index page:
package com.baw.website.pages;
import org.apache.tapestry5.EventContext;
import org.apache.tapestry5.services.HttpError;
public class Index
{
/**
* Restore 404 Not Found errors
* @param context
* @return
*/
HttpError onActivate(EventContext context)
{
if (context.getCount() == 0)
{
return null;
}
return new HttpError(404, "Resource not found.");
}
}
And then add tapestry filter to error processing and have a tapestry NotFound
page.
Works great!
On Jan 27, 2013, at 1:16 PM, Massimo Lusetti wrote:
> I'm interested in implementing the handling of requests to nonexistent
> pages.
>
> This is something that has to work nicely with the concept of "activation
> context" that tapestry5 has since day one.
>
> Now my solution would be to have the platform (tapestry5) to signal with a
> 404 error when it encounter a request to a nonexistent page or to a page
> with the wrong activation context parameter.
>
> Before going any further I would like to ask for suggestion on how you
> envision the situation or to know your experience in the fields.
>
> How do you handle requests to page that actually don't exists in your
> tapestry5 applications?
>
> Cheers
> --
> Massimo
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Tapestry 5.4-alpha-2
5.4-alpha-x should not be a snapshot at all. It's a release. An alpha release, but a release. 5.4-SNAPSHOT should be the bleeding edge nightly builds. On Jan 22, 2013, at 6:54 AM, Massimo Lusetti wrote: > I feel lazy but now I think I understood what Uli was talking about. > > If you look at the apache snapshot repository, for example the IoC: > https://repository.apache.org/content/groups/snapshots/org/apache/tapestry/tapestry-ioc/ > > You can see that the latest snapshot is 5.4-alpha-3-SNAPSHOT instead of > 5.4-SNAPSHOT > > I do agree that having a "frozen snapshot" like 5.4-alpha-3 is a very good > idea for the early adopters but the latest snapshot has to remain > 5.4-SNAPSHOT which is the real bleeding edge and used by T5 developers. > > So what Jenkins builds should go with 5.4-SNAPSHOT while if we want to > produce an intermediate release for early adopters we should change it to > 5.4-alpha-x or whatever applicable. > > Thoughts!? > > > On Tue, Jan 8, 2013 at 12:40 AM, Massimo Lusetti wrote: > >> I do agree, having the possibility to specify a precise target as a dep >> while testing an upgrade is by far a better solution then having a moving >> target >> > > > > -- > 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: [2/2] git commit: TAP5-2049: Use a lock when reading/updating HttpSession attributes - Add a symbol to deactivate the session locking logic
Absolutely. This is too big of a change to force on all framework users On Jan 18, 2013, at 1:58 PM, "Thiago H de Paula Figueiredo" wrote: > In the end, aren't the correct synchronization approach too specific for each > scenario for a web framework to provide them? The atomicity problem described > in the article is almost only solvable by turning data immutable, the stored > object itself taking care of synchronization or the code that uses the data > doing that (the AtomicReference example). > > Anyway, I think the default value for the symbol that turns on or off the > Tapestry session synchronization feature should be false (disabled). > > On Fri, 18 Jan 2013 17:47:36 -0200, Howard Lewis Ship > wrote: > >> Please read http://www.ibm.com/developerworks/library/j-jtp09238/index.html >> >> Because attributes in the HttpSession may be mutable, we acquire an >> exclusive write lock when reading attributes. >> >> Deadlock hell would be the annotation based approach being discussed, where >> there are any number of paths to the point where a lock occurs. >> >> I haven't had a chance to pull up the discussion that led me down this >> path, beyond Brian's article above. I value robustness and thread safety >> above other concerns. >> >> On Fri, Jan 18, 2013 at 6:04 AM, Nelson Rodrigues < >> nel...@nelsonjrodrigues.com> wrote: >> >>> Hello, >>> >>> This to me seems like a one way ticket to deadlock-land. Unless you're >>> able to define a strict lock hierarchy and always acquire locks in the >>> same exact order, this option will be extremely difficult for >>> application developers to use correctly. >>> >>> Just my 2 cents. >>> >>> Cheers, >>> Nelson. >>> >>> >>> >>> On 18/01/2013, at 11:11, Thiago H de Paula Figueiredo >>> wrote: >>> >>> >> Also, I find it much to coarse-grained to either enable it for the >>> whole application or for nothing. >>> > >>> > Agreed too. It seems it's a lock on the whole session (am I right?), >>> something that doesn't make sense at first to me. When two different >>> threads accessing different attributes in the session at the same time, >>> none should be blocked. Why not a lock per session attribute? Or per >>> @Persist field or @SessionState type? >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: dev-h...@tapestry.apache.org > > > -- > Thiago H. de Paula Figueiredo > > - > 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: TAP5-2049 - Exclusive session access
Or at worst, make it optional, turned off by default. On Jan 14, 2013, at 8:19 AM, Felix Scheffer wrote: > How about ReentrantReadWriteLock instead of ReentrantLock. Requests could > read data from the session simultaneously until a request is actually > writing to the session. > > Felix > > 2013/1/14 Howard Lewis Ship > >> And I've had equal discussion from others demanding this feature, so there >> you go. >> >> On Sunday, January 13, 2013, Lenny Primak wrote: >> >>> Howard, is there a particular use case for this? This sounds like an >>> overkill and unnecessary. >>> There are also most likely locking going on just to get to the per thread >>> access to the field even before the session gets accessed. >>> I view is change as a performance killer as well with no benefits >>> whatsoever. >>> >>> Good catch Denis. >>> >>> On Jan 13, 2013, at 5:57 AM, Denis Stepanov > > >>> wrote: >>> >>>> Changes introduced in >> https://issues.apache.org/jira/browse/TAP5-2049bring some bad >> consequences. >>>> >>>> Now, if your request accesses the session every other request will wait >>> to access the session until the previous request is done, it means long >>> running request could block all other requests, this bring major >>> performance issues. >>>> >>>> Some points I have mentioned in the comments: >>>> >>>> - We have many concurrent ajax request, this change means major >>> performance issue for us! >>>> - This will not work in a clustered environment, the clustered session >>> class shouldn't inherit the locks functionality. >>>> - Tapestry should not do this by default, any kind of synchronization >>> between the requests is bad idea and should be avoided at any cost. >>>> >>>> Cases when you need to synchronize session's state should be dealt with >>> individually, not forcing everyone into using it. >>>> >>>> Tapestry should not try to outsmart the servlet specification, the >>> session object should only be wrapping the HttpSession without bringing >>> some major behavior changes. Session synchronization is anti-pattern and >>> should not be promoted in a first place. >>>> >>>> Denis >>> >>> - >>> 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 >> - 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
Oh I read the code. It's about the other parts of request processing that make session lock unnecessary in all but most esoteric cases. On Jan 13, 2013, at 10:17 PM, Kalle Korhonen wrote: > On Sun, Jan 13, 2013 at 7:46 PM, Lenny Primak wrote: > >> Perhaps a few more details are in order? Is this for SSOs, @Perstst >> objects? >> Sounds like a crutch. >> If this has to do with per thread objects wouldn't those be already locked >> anyway? > > Again, it's an open source project. There's no point discussing this if you > don't bother taking a look at the code. > https://github.com/apache/tapestry-5/blob/master/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/SessionImpl.java > > Kalle > > >> >> >> On Jan 13, 2013, at 6:54 PM, Howard Lewis Ship wrote: >> >>> And I've had equal discussion from others demanding this feature, so >> there >>> you g >>> On Sunday, January 13, 2013, Lenny Primak wrote: >>> >>>> Howard, is there a particular use case for this? This sounds like an >>>> overkill and unnecessary. >>>> There are also most likely locking going on just to get to the per >> thread >>>> access to the field even before the session gets accessed. >>>> I view is change as a performance killer as well with no benefits >>>> whatsoever. >>>> >>>> Good catch Denis. >>>> >>>> On Jan 13, 2013, at 5:57 AM, Denis Stepanov > > >>>> wrote: >>>> >>>>> Changes introduced in >> https://issues.apache.org/jira/browse/TAP5-2049bring some bad >> consequences. >>>>> >>>>> Now, if your request accesses the session every other request will wait >>>> to access the session until the previous request is done, it means long >>>> running request could block all other requests, this bring major >>>> performance issues. >>>>> >>>>> Some points I have mentioned in the comments: >>>>> >>>>> - We have many concurrent ajax request, this change means major >>>> performance issue for us! >>>>> - This will not work in a clustered environment, the clustered session >>>> class shouldn't inherit the locks functionality. >>>>> - Tapestry should not do this by default, any kind of synchronization >>>> between the requests is bad idea and should be avoided at any cost. >>>>> >>>>> Cases when you need to synchronize session's state should be dealt with >>>> individually, not forcing everyone into using it. >>>>> >>>>> Tapestry should not try to outsmart the servlet specification, the >>>> session object should only be wrapping the HttpSession without bringing >>>> some major behavior changes. Session synchronization is anti-pattern and >>>> should not be promoted in a first place. >>>>> >>>>> Denis >>>> >>>> - >>>> 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 >> >> - >> 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: TAP5-2049 - Exclusive session access
Perhaps a few more details are in order? Is this for SSOs, @Perstst objects? Sounds like a crutch. If this has to do with per thread objects wouldn't those be already locked anyway? On Jan 13, 2013, at 6:54 PM, Howard Lewis Ship wrote: > And I've had equal discussion from others demanding this feature, so there > you go. > > On Sunday, January 13, 2013, Lenny Primak wrote: > >> Howard, is there a particular use case for this? This sounds like an >> overkill and unnecessary. >> There are also most likely locking going on just to get to the per thread >> access to the field even before the session gets accessed. >> I view is change as a performance killer as well with no benefits >> whatsoever. >> >> Good catch Denis. >> >> On Jan 13, 2013, at 5:57 AM, Denis Stepanov >> > >> wrote: >> >>> Changes introduced in https://issues.apache.org/jira/browse/TAP5-2049bring >>> some bad consequences. >>> >>> Now, if your request accesses the session every other request will wait >> to access the session until the previous request is done, it means long >> running request could block all other requests, this bring major >> performance issues. >>> >>> Some points I have mentioned in the comments: >>> >>> - We have many concurrent ajax request, this change means major >> performance issue for us! >>> - This will not work in a clustered environment, the clustered session >> class shouldn't inherit the locks functionality. >>> - Tapestry should not do this by default, any kind of synchronization >> between the requests is bad idea and should be avoided at any cost. >>> >>> Cases when you need to synchronize session's state should be dealt with >> individually, not forcing everyone into using it. >>> >>> Tapestry should not try to outsmart the servlet specification, the >> session object should only be wrapping the HttpSession without bringing >> some major behavior changes. Session synchronization is anti-pattern and >> should not be promoted in a first place. >>> >>> Denis >> >> - >> 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 - 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
Howard, is there a particular use case for this? This sounds like an overkill and unnecessary. There are also most likely locking going on just to get to the per thread access to the field even before the session gets accessed. I view is change as a performance killer as well with no benefits whatsoever. Good catch Denis. On Jan 13, 2013, at 5:57 AM, Denis Stepanov wrote: > Changes introduced in https://issues.apache.org/jira/browse/TAP5-2049 bring > some bad consequences. > > Now, if your request accesses the session every other request will wait to > access the session until the previous request is done, it means long running > request could block all other requests, this bring major performance issues. > > Some points I have mentioned in the comments: > > - We have many concurrent ajax request, this change means major performance > issue for us! > - This will not work in a clustered environment, the clustered session class > shouldn't inherit the locks functionality. > - Tapestry should not do this by default, any kind of synchronization between > the requests is bad idea and should be avoided at any cost. > > Cases when you need to synchronize session's state should be dealt with > individually, not forcing everyone into using it. > > Tapestry should not try to outsmart the servlet specification, the session > object should only be wrapping the HttpSession without bringing some major > behavior changes. Session synchronization is anti-pattern and should not be > promoted in a first place. > > Denis - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Cleaning up JIRA
Agreed. I think that if after owner notification and about a month waiting period, the issue can be closed. On Dec 18, 2012, at 12:29 PM, Kalle Korhonen wrote: > Uli, let's not make this a religious argument. If we all compromise a bit > we'll see that everyone wants the same thing, a smaller open bug count. Can > we just wait a bit for bulk closing anything, and in the meanwhile keep > sending a message that the time to take a look at the open issues is right > now; we'll be bulk closing, say after 5.4. is in beta. I know I have a few > ones I've been scrambling to find some time to work on. > > Kalle > > > On Tue, Dec 18, 2012 at 7:14 AM, Ulrich Stärk wrote: > >> And my objection is to wasting resources on going through every issue and >> in the end still closing >> most of them. >> >> If Robert wants to spend the time on it, I'm all for it. But I really want >> to see the list of open >> issues significantly reduced in the near future and I believe that the >> mose time effective solution >> is simply to close old ones as won't fix. >> >> Uli >> >> On 18.12.2012 12:55, Bob Harner wrote: >>> Uli, my only objection is to bulk closing the issues. >>> On Dec 18, 2012 6:52 AM, "Ulrich Stärk" wrote: >>> Ok, so we keep piling them up because we don't want to hurt people's feelings? Don't you think that people deserve to be told the truth: "Guys, we are sorry, but this stuff is old, we most likely won't look at it ever because we have a lot of other tasks with higher priorities, but if you feel this is still an issue please confirm with a newer version of Tapestry"? Same goes for feature requests. If we really cared we could have implemented those old >> requests by now, but we don't. So let's be honest and tell our users that we might find the ideas interesting but lack time to implement them. Everything else is just lying to ourselves and our users that we will someday - maybe - look at it. So let's be honest and tell them what they know anyway: "Won't fix". Uli On 18.12.2012 12:38, Bob Harner wrote: > Robert Z. has volunteered to prune the list manually. I think we should see > where that gets us. > > Let's not forget that every bug report represents a significant investment > of time by a Tapestry user who earnestly wants to make the framework > better, and we definitely want to encourage that. A few of the bugs are > pure junk, but many are well-described, with good proposed solutions, > patches and, yes, even tests in some cases. > > I know if I were to submit a thoughtful bug report or patch to an open > source project and it got casually rejected by an automated process >> (and I > was told not to reopen it), I would be greatly discouraged from making any > further contributions. > > > > > On Tue, Dec 18, 2012 at 2:37 AM, Ulrich Stärk >> wrote: > >> Folks, there is no sense in hording issues that we know will never be >> addressed and that do nothing >> else but clutter our issue tracker and block our view on the really useful >> ones. Please overcome the >> gatherer in you. Even the best idea won't help us if there is nobody >> interested in implementing it >> and it only contributes to obstrucing our view on important issues. >> Besides, those tickets aren't >> gone. They are simply closed. >> >> Below is a draft of a text that I'm going to attach to the issues that >> will be bulk closed. It makes >> clear that the reporter is free to reopen the issue if it still >> persists >> or he feels strongly about >> it. In case of a feature request they are required to discuss it on >> the >> dev mailing list first. I >> hope that this will increase the chances of having only well >> thought-out >> ideas that are also >> supported by the development community in our tracker. >> >> And I really recommend reading [1]. >> >> Cheers, >> >> Uli >> >> [1] http://www.joelonsoftware.com/items/2012/07/09.html >> >> >> This issue has been closed because it affects an old version of >> Tapestry >> or has no affected version >> number set, and is not currently assigned to any developer. >> >> This ticket will most likely never be resolved or already has been >> resolved as a side-effect of a >> newer version of Tapestry. >> >> >> DO NOT REOPEN IT! DO NOT CREATE A NEW TICKET WITH THE SAME CONTENT! >> >> >> If you feel that the issue still persists, do the following: >> >> 1. Try again with the most recent version of Apache Tapestry >> >> 2a. If you still find a bug, open a new bug report, specify the exact >> version of Tapestry and those >> of any components you are using, describe exp
Re: removing the HTML DTD declaration for HTML5 compliance
Latest tapestry supports this out of the box. On Dec 14, 2012, at 4:20 PM, Jon Williams wrote: > Hi, > > I want to remove the HTML DTD declaration for HTML5 compliance. > > I found this site. > http://www.atentia.net/2011/02/tapestry5-setup-with-html5-and-jquery/ > But it mentions that you have to patch a Tapestry class to make it work. > Shouldn't this be just configurable with some kind of contribution? > > Is there a better way to do this? > > thanks - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Idea for 5.4: ControlGroup mixin
This I just a reminder for the dev folks how important designer fidelity is. Most Devs including me sometimes forget that. On Dec 13, 2012, at 5:23 PM, "Thiago H de Paula Figueiredo" wrote: > On Thu, 13 Dec 2012 19:40:52 -0200, Lenny Primak > wrote: > >> That does not solve the problem of editing the templates in DreamWeaver >> and seeing the changes right away, without Tapestry, database, etc. >> When I give my templates to the designer, they will just run DW on it, >> that's all. It is very important to be able to keep the DW-friendly syntax >> n Tapestry. Thats #1 feature in Tapestry for me. No other framework does >> this as well now. > > I know what you're talking, I also work with designers (not in person) and I > agree that previewability is awesome. I just don't understand your concern > here. Besides simple form field components, all others generate HTML beyond > its declaration and wouldn't be 100% previewable anyway (Grid, BeanEditor, > etc). In addition, the proposed mixin, as any other mixin, is optional. If > you want to keep the template as closer to the generated HTML, all you need > to do is not to use it. In other words, do nothing. > > -- > Thiago H. de Paula Figueiredo > > - > 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: Idea for 5.4: ControlGroup mixin
That does not solve the problem of editing the templates in DreamWeaver and seeing the changes right away, without Tapestry, database, etc. When I give my templates to the designer, they will just run DW on it, that's all. It is very important to be able to keep the DW-friendly syntax n Tapestry. Thats #1 feature in Tapestry for me. No other framework does this as well now. On Dec 13, 2012, at 4:16 PM, Howard Lewis Ship wrote: > Highest fidelity is "gradle runJetty", or some special target just for the > designers. > > > On Thu, Dec 13, 2012 at 1:15 PM, Howard Lewis Ship wrote: > >> So, be glad it is optional! >> >> Some day, I hope to be in a position where that is an issue; where I get >> to work directly with a designer. That has not been the case for > 10 >> years. That's why I love Bootstrap as much as I do ... it gives me 80+% of >> the benefit of working with a designer, without the actual designer. >> >> >> On Thu, Dec 13, 2012 at 1:00 PM, Lenny Primak wrote: >> >>> I chose Tapestry for my projects because you can freely share templates >>> with >>> DreamWeaver and Photoshop-using designers. They need to be able to see >>> with the highest fidelity and modify with the highest accuracy. >>> Sometimes, our more advanced Tapestry-using friends might forget that :) >>> >>> On Dec 13, 2012, at 3:13 PM, "Thiago H de Paula Figueiredo" < >>> thiag...@gmail.com> wrote: >>> >>>> On Thu, 13 Dec 2012 16:31:08 -0200, Lenny Primak < >>> lpri...@hope.nyc.ny.us> wrote: >>>> >>>>> Nice. I like it. The only issue may be dreamweaver etc. fidelity. >>>> >>>> It's optional, so that won't be an issue. I still prefer the >> type="text" t:type="TextField"/> syntax. >>>> >>>> -- >>>> Thiago H. de Paula Figueiredo >>>> >>>> - >>>> 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 >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Idea for 5.4: ControlGroup mixin
I chose Tapestry for my projects because you can freely share templates with DreamWeaver and Photoshop-using designers. They need to be able to see with the highest fidelity and modify with the highest accuracy. Sometimes, our more advanced Tapestry-using friends might forget that :) On Dec 13, 2012, at 3:13 PM, "Thiago H de Paula Figueiredo" wrote: > On Thu, 13 Dec 2012 16:31:08 -0200, Lenny Primak > wrote: > >> Nice. I like it. The only issue may be dreamweaver etc. fidelity. > > It's optional, so that won't be an issue. I still prefer the type="text" t:type="TextField"/> syntax. > > -- > Thiago H. de Paula Figueiredo > > - > 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: Idea for 5.4: ControlGroup mixin
Nice. I like it. The only issue may be dreamweaver etc. fidelity. On Dec 13, 2012, at 1:28 PM, Howard Lewis Ship wrote: > Because of Bootstrap, there's a bit more boilerplate in the template; for > instance, editting a field may look like: > > > > > > > > > > ... > > I think we can reduce the boilerplate to: > > > > ControlGroup mixin can generate the extra elements, and emulate the > Label component as well. > > I'll be working on ideas like this after the first alpha ... unless someone > beats me to it! > > -- > 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: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities not associated with correct entity manager issue
I just took a quick look (but not tested) at your code, and I don't see how not
caching a proxy has any difference.
Since the PlasticProxyFactory calls createObject() upon every method call.
I just tested a simple app with two PUs on the same page and it works fine.
I still say this is not an issue.
On Nov 13, 2012, at 8:55 PM, John wrote:
> please see https://issues.apache.org/jira/browse/TAP5-2027
> - Original Message -
> From: Lenny Primak
> To: Tapestry development
> Sent: Wednesday, November 14, 2012 1:21 AM
> Subject: Re: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities
> not associated with correct entity manager issue
>
>
> I didn't look at this in detail, but proxies are sometimes thread-local, and
> not really singletons.
> Also, your patch isn't a real patch. it's a replacement, and harder to
> incorporate for committers,
> if it is indeed necessary.
>
> On Nov 13, 2012, at 8:09 PM, John wrote:
>
>> Hi,
>>
>> The original code is like below, note how the proxy provided acts like a
>> singleton. I'll take a look at the JIRA, thanks.
>>
>> public class EntityManagerObjectProvider implements ObjectProvider
>> {
>> private EntityManager proxy;
>> public T provide(final Class objectType, final AnnotationProvider
>> annotationProvider,
>> final ObjectLocator locator)
>> {
>> if (objectType.equals(EntityManager.class))
>> return objectType.cast(getOrCreateProxy(annotationProvider,
>> locator));
>> return null;
>> }
>>
>> private synchronized EntityManager getOrCreateProxy(
>> final AnnotationProvider annotationProvider, final ObjectLocator
>> objectLocator)
>> {
>> if (proxy == null)
>> {
>> ...
>> }
>> return proxy;
>> - Original Message -
>> From: Lenny Primak
>> To: Tapestry development
>> Cc:
>> Sent: Wednesday, November 14, 2012 12:52 AM
>> Subject: Re: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities
>> not associated with correct entity manager issue
>>
>>
>> I am not sure why the existing code doesn't work for you as it works fine in
>> my environment.
>> Another thing is that patches belong in JIRA and cannot be taken from
>> mailing lists due to copyright issues.
>>
>> Perhaps Igor can shed some light on this?
>>
>> On Nov 13, 2012, at 7:48 PM, "John" wrote:
>>
>>> I put this on the users group recently to complete a thread, it belongs
>>> here really I suppose.
>>>
>>> The problem manifests when multiple PUs are defined in persistence.xml and
>>> then referred to in classes using the @PersistenceContext(unitName=
>>> annotation. As it is in 5.3.6 the first EntityManager wired up gets
>>> injected to all successive EntityManager instances and the unitName= value
>>> is ignored. Probem was caused by reusing a class variable. The bug makes it
>>> seem that entities are not wired to the EntityManager as you would expect,
>>> in fact the reference passed in is bad.
>>>
>>> Also refactored to use PlasticProxyFactory.
>>>
>>> John
>>>
>>>
>>> - Original Message - From: John
>>> To: Tapestry users
>>> Sent: Tuesday, November 13, 2012 7:51 AM
>>> Subject: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities not
>>> associated with correct entity manager issue
>>>
>>>
>>> This looks like a bug where a class member variable is used to cache the
>>> EntityManager that is subsequently handed to all the PersistenceContext
>>> annotations regardless of the unitName, like I said.
>>>
>>> The following replacement class is tested working and handles multiple
>>> persistence units correctly as per the original Tapestry docs, just put it
>>> on your classpath first. Maybe someone on the developer side can check this
>>> out and commit it to the build cycle.
>>>
>>>
>>> package org.apache.tapestry5.internal.jpa;
>>>
>>> import javax.persistence.EntityManager;
>>> import javax.persistence.PersistenceContext;
>>>
>>> import org.apache.tapestry5.ioc.AnnotationProvider;
>>> import org.apache.tapestry5.ioc.ObjectCreator;
>>> import org.apache.tapestry5.ioc.ObjectLocator;
>>> import org.apache.tapestry5.ioc.ObjectProvider;
>>> import org.apache.tapestry5.ioc.service
Re: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities not associated with correct entity manager issue
That's still not a patch. Patches look like this:
http://guide.macports.org/chunked/development.patches.html
If you attach that to the JIRA you have a better chance of someone looking at
it.
On Nov 13, 2012, at 8:37 PM, John wrote:
> I got the original source code from tapestry-jpa version 5.3.6 which I see is
> not registered in the JIRA, so I can't report this bug. Perhaps this is only
> in this version, I will try another.
>
> It is more like a refactor as provided.
>
> As a patch
> removethe private EntityManager proxy line
> removeif (proxy == null) {}conditionality code block wrapping
>
> This also works and was my original code change until I saw depricated
> classes being used.
>
> John
>
>
> - Original Message -
> From: Lenny Primak
> To: Tapestry development
> Sent: Wednesday, November 14, 2012 1:21 AM
> Subject: Re: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities
> not associated with correct entity manager issue
>
>
> I didn't look at this in detail, but proxies are sometimes thread-local, and
> not really singletons.
> Also, your patch isn't a real patch. it's a replacement, and harder to
> incorporate for committers,
> if it is indeed necessary.
>
> On Nov 13, 2012, at 8:09 PM, John wrote:
>
>> Hi,
>>
>> The original code is like below, note how the proxy provided acts like a
>> singleton. I'll take a look at the JIRA, thanks.
>>
>> public class EntityManagerObjectProvider implements ObjectProvider
>> {
>> private EntityManager proxy;
>> public T provide(final Class objectType, final AnnotationProvider
>> annotationProvider,
>> final ObjectLocator locator)
>> {
>> if (objectType.equals(EntityManager.class))
>> return objectType.cast(getOrCreateProxy(annotationProvider,
>> locator));
>> return null;
>> }
>>
>> private synchronized EntityManager getOrCreateProxy(
>> final AnnotationProvider annotationProvider, final ObjectLocator
>> objectLocator)
>> {
>> if (proxy == null)
>> {
>> ...
>> }
>> return proxy;
>> - Original Message -
>> From: Lenny Primak
>> To: Tapestry development
>> Cc:
>> Sent: Wednesday, November 14, 2012 12:52 AM
>> Subject: Re: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities
>> not associated with correct entity manager issue
>>
>>
>> I am not sure why the existing code doesn't work for you as it works fine in
>> my environment.
>> Another thing is that patches belong in JIRA and cannot be taken from
>> mailing lists due to copyright issues.
>>
>> Perhaps Igor can shed some light on this?
>>
>> On Nov 13, 2012, at 7:48 PM, "John" wrote:
>>
>>> I put this on the users group recently to complete a thread, it belongs
>>> here really I suppose.
>>>
>>> The problem manifests when multiple PUs are defined in persistence.xml and
>>> then referred to in classes using the @PersistenceContext(unitName=
>>> annotation. As it is in 5.3.6 the first EntityManager wired up gets
>>> injected to all successive EntityManager instances and the unitName= value
>>> is ignored. Probem was caused by reusing a class variable. The bug makes it
>>> seem that entities are not wired to the EntityManager as you would expect,
>>> in fact the reference passed in is bad.
>>>
>>> Also refactored to use PlasticProxyFactory.
>>>
>>> John
>>>
>>>
>>> - Original Message - From: John
>>> To: Tapestry users
>>> Sent: Tuesday, November 13, 2012 7:51 AM
>>> Subject: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities not
>>> associated with correct entity manager issue
>>>
>>>
>>> This looks like a bug where a class member variable is used to cache the
>>> EntityManager that is subsequently handed to all the PersistenceContext
>>> annotations regardless of the unitName, like I said.
>>>
>>> The following replacement class is tested working and handles multiple
>>> persistence units correctly as per the original Tapestry docs, just put it
>>> on your classpath first. Maybe someone on the developer side can check this
>>> out and commit it to the build cycle.
>>>
>>>
>>> package org.apache.tapestry5.internal.jpa;
>>>
>>> import javax.persistence.EntityManag
Re: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities not associated with correct entity manager issue
I didn't look at this in detail, but proxies are sometimes thread-local, and
not really singletons.
Also, your patch isn't a real patch. it's a replacement, and harder to
incorporate for committers,
if it is indeed necessary.
On Nov 13, 2012, at 8:09 PM, John wrote:
> Hi,
>
> The original code is like below, note how the proxy provided acts like a
> singleton. I'll take a look at the JIRA, thanks.
>
> public class EntityManagerObjectProvider implements ObjectProvider
> {
>private EntityManager proxy;
>public T provide(final Class objectType, final AnnotationProvider
> annotationProvider,
>final ObjectLocator locator)
>{
>if (objectType.equals(EntityManager.class))
>return objectType.cast(getOrCreateProxy(annotationProvider,
> locator));
>return null;
>}
>
>private synchronized EntityManager getOrCreateProxy(
>final AnnotationProvider annotationProvider, final ObjectLocator
> objectLocator)
>{
>if (proxy == null)
>{
> ...
>}
>return proxy;
> - Original Message -
> From: Lenny Primak
> To: Tapestry development
> Cc:
> Sent: Wednesday, November 14, 2012 12:52 AM
> Subject: Re: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities
> not associated with correct entity manager issue
>
>
> I am not sure why the existing code doesn't work for you as it works fine in
> my environment.
> Another thing is that patches belong in JIRA and cannot be taken from
> mailing lists due to copyright issues.
>
> Perhaps Igor can shed some light on this?
>
> On Nov 13, 2012, at 7:48 PM, "John" wrote:
>
>> I put this on the users group recently to complete a thread, it belongs here
>> really I suppose.
>>
>> The problem manifests when multiple PUs are defined in persistence.xml and
>> then referred to in classes using the @PersistenceContext(unitName=
>> annotation. As it is in 5.3.6 the first EntityManager wired up gets injected
>> to all successive EntityManager instances and the unitName= value is
>> ignored. Probem was caused by reusing a class variable. The bug makes it
>> seem that entities are not wired to the EntityManager as you would expect,
>> in fact the reference passed in is bad.
>>
>> Also refactored to use PlasticProxyFactory.
>>
>> John
>>
>>
>> - Original Message - From: John
>> To: Tapestry users
>> Sent: Tuesday, November 13, 2012 7:51 AM
>> Subject: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities not
>> associated with correct entity manager issue
>>
>>
>> This looks like a bug where a class member variable is used to cache the
>> EntityManager that is subsequently handed to all the PersistenceContext
>> annotations regardless of the unitName, like I said.
>>
>> The following replacement class is tested working and handles multiple
>> persistence units correctly as per the original Tapestry docs, just put it
>> on your classpath first. Maybe someone on the developer side can check this
>> out and commit it to the build cycle.
>>
>>
>> package org.apache.tapestry5.internal.jpa;
>>
>> import javax.persistence.EntityManager;
>> import javax.persistence.PersistenceContext;
>>
>> import org.apache.tapestry5.ioc.AnnotationProvider;
>> import org.apache.tapestry5.ioc.ObjectCreator;
>> import org.apache.tapestry5.ioc.ObjectLocator;
>> import org.apache.tapestry5.ioc.ObjectProvider;
>> import org.apache.tapestry5.ioc.services.PlasticProxyFactory;
>> import org.apache.tapestry5.jpa.EntityManagerManager;
>>
>> /**
>> * A patched version to use PlasticProxyFactory and not cache the
>> EntityManager as a class member.
>> * @author John Coleman
>> */
>> public class EntityManagerObjectProvider implements ObjectProvider
>> {
>>
>> /**
>> * {@inheritDoc}
>> */
>> public T provide(final Class objectType, final AnnotationProvider
>> annotationProvider,
>> final ObjectLocator locator)
>> {
>> if (objectType.equals(EntityManager.class))
>> return objectType.cast(getOrCreateProxy(annotationProvider,
>> locator));
>>
>> return null;
>> }
>>
>> private synchronized EntityManager getOrCreateProxy(
>> final AnnotationProvider annotationProvider, final ObjectLocator
>> objectLocator)
>> {
>> final PlasticProxyFactory proxyFactory =
>> objec
Re: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities not associated with correct entity manager issue
I am not sure why the existing code doesn't work for you as it works fine in my
environment.
Another thing is that patches belong in JIRA and cannot be taken from mailing
lists due to copyright issues.
Perhaps Igor can shed some light on this?
On Nov 13, 2012, at 7:48 PM, "John" wrote:
> I put this on the users group recently to complete a thread, it belongs here
> really I suppose.
>
> The problem manifests when multiple PUs are defined in persistence.xml and
> then referred to in classes using the @PersistenceContext(unitName=
> annotation. As it is in 5.3.6 the first EntityManager wired up gets injected
> to all successive EntityManager instances and the unitName= value is ignored.
> Probem was caused by reusing a class variable. The bug makes it seem that
> entities are not wired to the EntityManager as you would expect, in fact the
> reference passed in is bad.
>
> Also refactored to use PlasticProxyFactory.
>
> John
>
>
> - Original Message - From: John
> To: Tapestry users
> Sent: Tuesday, November 13, 2012 7:51 AM
> Subject: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities not
> associated with correct entity manager issue
>
>
> This looks like a bug where a class member variable is used to cache the
> EntityManager that is subsequently handed to all the PersistenceContext
> annotations regardless of the unitName, like I said.
>
> The following replacement class is tested working and handles multiple
> persistence units correctly as per the original Tapestry docs, just put it on
> your classpath first. Maybe someone on the developer side can check this out
> and commit it to the build cycle.
>
>
> package org.apache.tapestry5.internal.jpa;
>
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
>
> import org.apache.tapestry5.ioc.AnnotationProvider;
> import org.apache.tapestry5.ioc.ObjectCreator;
> import org.apache.tapestry5.ioc.ObjectLocator;
> import org.apache.tapestry5.ioc.ObjectProvider;
> import org.apache.tapestry5.ioc.services.PlasticProxyFactory;
> import org.apache.tapestry5.jpa.EntityManagerManager;
>
> /**
> * A patched version to use PlasticProxyFactory and not cache the
> EntityManager as a class member.
> * @author John Coleman
> */
> public class EntityManagerObjectProvider implements ObjectProvider
> {
>
> /**
>* {@inheritDoc}
>*/
> public T provide(final Class objectType, final AnnotationProvider
> annotationProvider,
> final ObjectLocator locator)
> {
> if (objectType.equals(EntityManager.class))
> return objectType.cast(getOrCreateProxy(annotationProvider,
> locator));
>
> return null;
> }
>
> private synchronized EntityManager getOrCreateProxy(
> final AnnotationProvider annotationProvider, final ObjectLocator
> objectLocator)
> {
> final PlasticProxyFactory proxyFactory =
> objectLocator.getService("PlasticProxyFactory",
> PlasticProxyFactory.class);
>
>final PersistenceContext annotation = annotationProvider
> .getAnnotation(PersistenceContext.class);
>
> EntityManager proxy = proxyFactory.createProxy(EntityManager.class,
> new ObjectCreator()
> {
> public EntityManager createObject()
> {
> final EntityManagerManager entityManagerManager =
> objectLocator
> .getService(EntityManagerManager.class);
>
> return
> JpaInternalUtils.getEntityManager(entityManagerManager, annotation);
> }
> }, "");
>
> return proxy;
> }
>
> }
>
> -
> 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: [PATCH] TAP5-1858 Cookie service should allow to set path, domain AND maxAge - Please apply to 5.3, Thank you!
Additional methods are easy, and not incompatible. I say just stick with the
original Cookie interface.
On Nov 13, 2012, at 9:59 AM, Ulrich Stärk wrote:
> The Cookies interface and implementation can use some love. I'll take care of
> that. Do we want to
> simply add a new method to the interface or should we create Cookies2 for
> backward compatibility?
>
> I tend to Cookies2.
>
> Uli
>
> On 13.11.2012 14:51, Michael Wyraz wrote:
>> From a54fdc541054a4fad654f31b0467b315812effd9 Tue, 13 Nov 2012 14:51:08 +0100
>> From: Michael Wyraz
>> Date: Tue, 13 Nov 2012 14:40:22 +0100
>> Subject: [PATCH] TAP5-1858 Cookie service should allow to set path, domain
>> AND maxAge
>>
>> diff --git
>> a/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/CookiesImpl.java
>> b/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/CookiesImpl.java
>> index 3c88006..adc26e4 100644
>> ---
>> a/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/CookiesImpl.java
>> +++
>> b/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/CookiesImpl.java
>> @@ -121,6 +121,19 @@
>>
>> cookieSink.addCookie(cookie);
>> }
>> +
>> +public void writeCookieValue(String name, String value, String path,
>> String domain, int maxAge)
>> +{
>> +Cookie cookie = new Cookie(name, value);
>> +if (path==null) cookie.setPath(request.getContextPath() + "/");
>> +else cookie.setPath(path);
>> +if (domain!=null) cookie.setDomain(domain);
>> +if (maxAge!=0) cookie.setMaxAge(maxAge);
>> +else cookie.setMaxAge(defaultMaxAge);
>> +cookie.setSecure(request.isSecure());
>> +
>> +cookieSink.addCookie(cookie);
>> +}
>>
>> public void removeCookieValue(String name)
>> {
>> diff --git
>> a/tapestry-core/src/main/java/org/apache/tapestry5/services/Cookies.java
>> b/tapestry-core/src/main/java/org/apache/tapestry5/services/Cookies.java
>> index 4bcd653..a081a6d 100644
>> --- a/tapestry-core/src/main/java/org/apache/tapestry5/services/Cookies.java
>> +++ b/tapestry-core/src/main/java/org/apache/tapestry5/services/Cookies.java
>> @@ -67,6 +67,11 @@
>> void writeCookieValue(String name, String value, String path, String
>> domain);
>>
>> /**
>> + * As with {@link #writeCookieValue(String, String, String)} but an
>> explicit domain,path and
>> maximum age may be set.
>> + */
>> +void writeCookieValue(String name, String value, String path, String
>> domain, int maxAge);
>> +
>> +/**
>> * Removes a previously written cookie, by writing a new cookie with a
>> maxAge of 0.
>> */
>> void removeCookieValue(String name);
>>
>> -
>> 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: Multi language support issue for Browse button in Tapestry upload
I loved that!
On Nov 9, 2012, at 6:22 AM, Bob Harner wrote:
> See http://lmgtfy.com/?q=How+to+change+Browse+button+Label :-)
>
>
> On Mon, Nov 5, 2012 at 10:38 AM, csnp wrote:
>
>> Hi,
>> How to change Browse button Label for multi language support in Tapestry5
>> ?
>>
>>
>>
>> I would like to know the attribute to change the Browser button label like
>> below
>> > label="${message:labelvalue}" >
>>
>> Please find the attachment for Browser button which is showing in English
>> and suppose to show in Spanish, I appreciate any of your tips or suggestion
>> to fix this , thanks in advance
>> Regards
>> CSNPrasad
>>
>> <
>> http://tapestry.1045711.n5.nabble.com/file/n5717663/browserlable_language_issue.png
>>
>>
>>
>> --
>> View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Multi-language-support-issue-for-Browse-button-in-Tapestry-upload-tp5717663.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: Compatibility for 5.4
Now, don't jump on me for saying this, again, but I think it's time for T6. On Oct 19, 2012, at 7:41 PM, Howard Lewis Ship wrote: > I you've seen the commits, you know I've been attacking the > client-side JavaScript with a chainsaw. Not everything is working, > especially the tests (!), but what does work is kicking ass. > > However, maintaining backwards compatibility is proving to be a huge > challenge. > > Keeping all the components working is not going to be that hard; > neither will making them work with either foundation (Prototype or > jQuery). > > What is going to be increasingly hard to keeping the Tapestry and T5 > namespaces working the same as before. > > So the question is ... what are the downsides of just ignoring > compatibility? Again, this is strictly on the client side, and > relates to all the effectively un-documented JavaScript code scattered > about in the existing tapestry.js and t5-*.js libraries. > > I know this will affect my applications a bit; it means that 5.4 will > be a more difficult transition as my code has a lot of patches around > T5 limitations. Even so, I suspect it will be just a matter of a > couple of days to upgrade the existing app. > > -- > 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] Tapestry 5.3.6
Lenny Primak: +1 (non-binding) - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: HMAC signatures
I don't think that for lazy developers it needs to be secure at all :) On Oct 4, 2012, at 6:48 PM, Massimo Lusetti wrote: > I feel I was not clear enough. > > To protect the lazy developers, the newcomers or simply the unwary > user I would make the default value a random generated string with a > big warning in the log and a big "pay attention" in the docs and > release notes. > > This goes with the feeling that an expert developer which has to face > a deploy to a cluster is more heedful and would set the value to a > known and beefy one. > > The current implementation feels like a false sense of security for > the first type of developer even more by the fact that this has been > added lately to the plate (it could slip through to the newcomers) so > if a random generated string is not accepted I would make it required, > with a nice RuntimeException, if not set. > > 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 > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Ready for 5.3.6?
More than ready! I hate being on anything less than the latest and greatest version of Tapestry. Had to skip 5.3.5, the first time I had to do that with Tapestry. On Oct 4, 2012, at 6:18 PM, Howard Lewis Ship wrote: > I think it might be time for a 5.3.6. This is what I'm showing as fixed: > > > Release Notes - Tapestry 5 - Version 5.3.6 > > > > > ** Bug >* [TAP5-986] - A request can fail with an NPE in some cases, when > a Tapestry page is acting as the servlet container error page >* [TAP5-1903] - Client-side exception when a Zone containing a > Form with an Upload component is re-rendered >* [TAP5-2008] - Serialized object data stored on the client should > be HMAC signed and validated >* [TAP5-2009] - Downgrade bundled Prototype version back to 1.7 > > > > ** Improvement >* [TAP5-1996] - Add Severity.SUCCESS enum for alerts > > > > -- > 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: Tapestry 5.3.5 BACK OUT Prototype 1.7.1?
I don't understand. It says fix version 5.3.5, but wouldn't be a 5.3.6 or later with this backout? Thanks for the fix! On Oct 4, 2012, at 5:35 PM, Howard Lewis Ship wrote: > Your wish is my command: > > https://issues.apache.org/jira/browse/TAP5-2009 > > On Thu, Oct 4, 2012 at 2:03 PM, Lenny Primak wrote: >> Voted. >> >> On Oct 4, 2012, at 4:59 PM, Geoff Callender >> wrote: >> >>> Please vote for >>> https://issues.apache.org/jira/browse/TAP5-1989#comment-13469684 . >>> >>> On 04/10/2012, at 9:01 PM, AndyB wrote: >>> >>>> Is this happening? >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://tapestry.1045711.n5.nabble.com/Re-Tapestry-5-3-5-BACK-OUT-Prototype-1-7-1-tp5716095p5716631.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 >>> >> >> - >> 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 > > - > 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: Tapestry 5.3.5 BACK OUT Prototype 1.7.1?
Voted. On Oct 4, 2012, at 4:59 PM, Geoff Callender wrote: > Please vote for > https://issues.apache.org/jira/browse/TAP5-1989#comment-13469684 . > > On 04/10/2012, at 9:01 PM, AndyB wrote: > >> Is this happening? >> >> >> >> -- >> View this message in context: >> http://tapestry.1045711.n5.nabble.com/Re-Tapestry-5-3-5-BACK-OUT-Prototype-1-7-1-tp5716095p5716631.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 > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Submmiting bug fixes and their propagation to releases
Do you have a JIRA opened associated with this patch, is this patch attached to this JIRA? If not, it's a non-starter. If you did, please attach your JIRA to your e-mail, so its easy for a committer to apply your patch. On Sep 16, 2012, at 7:04 PM, bhorvat wrote: > http://tapestry.1045711.n5.nabble.com/file/n5716335/javascript_upload_rerender.patch > javascript_upload_rerender.patch > > I think that I have managed to create a patch. Can someone try to apply it > to see if it works? > > Also what is the procedure to push this into the branch? > > I have been using the fixed for the last few months and also it is a fairly > trivial fix > > tnx and cheers all > > > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/Submmiting-bug-fixes-and-their-propagation-to-releases-tp5715905p5716335.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: Tapestry 5.3.5 BACK OUT Prototype 1.7.1?
I completely agree with this. On Sep 7, 2012, at 10:50 AM, Ben Dotte wrote: > I'd vote to back it out personally. I assume the broken Prototype stuff > will be gone or replaced in 5.4 anyway, so it seems like a waste of effort. > > Ben > > On Fri, Sep 7, 2012 at 8:44 AM, trsvax wrote: > >> I try and stay current since upgrades have been mostly painless. In fact so >> far it's been 3rd party library upgrades such as Hibernate that have caused >> me the most problems. I guess the Hibernate one was necessary and now it >> looks like Prototype might introduce issues so I'll throw on my 2 cents. >> >> I have plenty of Prototype code but all my new development is jQuery. If I >> start a new project I turn Prototype off. If I have to work on older >> Prototype code I generally just convert it to jQuery. So my personal >> preference would be to leave the Prototype version alone because apparently >> if I upgrade to 5.3.5 I'm going to need to retest and possibly fix/convert >> old code. >> >> So my vote would be to never update Prototype. >> >> I realize my situation might be unique but I figured I'd just throw it out >> there. >> >> >> >> -- >> View this message in context: >> http://tapestry.1045711.n5.nabble.com/Re-Tapestry-5-3-5-BACK-OUT-Prototype-1-7-1-tp5716095p5716117.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.5 Take 2
Lenny Primak: -1 (non-binding) The new prototype version doesn't seem to be ready for prime time. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Apache Tapestry 5.3.5
Well for whatever reason it didn't work for me and I don't use a proxy. I'll try to find and fetch the docs for my jarjar solution shortly. On Aug 21, 2012, at 1:29 PM, Kalle Korhonen wrote: > On Tue, Aug 21, 2012 at 10:05 AM, Lenny Primak wrote: >> I don't think Maven works that way. The jar dependencies are just that, jar >> dependencies. >> Maven doesn't look and bring in the dependencies information. >> I believe that it's done by design that way. > > It does. Since the beginning of times, you've been able to specify > additional repositories in the pom. However the issue is that > nowadays, most people use a Maven proxy repository, which is according > to Maven best practices. You have to configure your proxy separately > with all the repos you want to use so you are back to square one. One > of the primary use cases for using a Maven proxy is exactly to prevent > Maven going out on the open Internet and fetching libraries from repos > of unknown quality. > > Kalle > > >> >> On Aug 21, 2012, at 12:57 PM, Howard Lewis Ship wrote: >> >>> See https://issues.apache.org/jira/browse/TAP5-1992 >>> >>> I don't understand why Maven doesn't pick up the element >>> in the tapestry-yuicompressor POM. >> \ >> - >> 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: [VOTE] Apache Tapestry 5.3.5
I don't think Maven works that way. The jar dependencies are just that, jar dependencies. Maven doesn't look and bring in the dependencies information. I believe that it's done by design that way. On Aug 21, 2012, at 12:57 PM, Howard Lewis Ship wrote: > See https://issues.apache.org/jira/browse/TAP5-1992 > > I don't understand why Maven doesn't pick up the element > in the tapestry-yuicompressor POM. \ - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [VOTE] Apache Tapestry 5.3.5
Lenny Primak: -1 (non-binding) The Play YUIcompressor is a showstopper for me. Tapestry should not force users to add maven repos other than maven central. My solution is to upload a jarjar-combined yuicompressor, tapestry-yuicompressor and rhino into one customized tapestry-yuicompressor, which solves the package name conflict beautifully. This can be found at http://flowlogix-m2.googlecode.com/svn/trunk/com/yahoo/platform/yui/yuicompressor/2.4.7-cust-tap-5.3.4/ - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: MongoDB modules for next 5.4
Not sure where, but I bet JSON to entity mappers exist somewhere already. No need to reinvent the wheel here. On Aug 16, 2012, at 3:27 PM, Howard Lewis Ship wrote: > I've been thinking of a general-purpose way to convert arbitrary > Objects into JSONObjects, using naming conventions and annotations. I > believe it could also be used to reverse the process. > > It would be nice for a Ajax event handler method to be able to return > an Entity, or a List and have that converted to a JSONObject, > or a JSONArray of JSONObjects automatically. It would also be nice to > have a ValueEncoder, or equivalent, be able to convert a JSONObject > back into an Object, knowing the target type. > > On Thu, Aug 16, 2012 at 11:47 AM, Thiago H de Paula Figueiredo > wrote: >> On Thu, 16 Aug 2012 14:34:35 -0300, Massimo Lusetti >> wrote: >> >>> Hi all, >> >> >> Hi! >> >> >>> I've done some preliminar work on two modules for integration with >>> MongoDB. >> >> >> Nice! I was thinking of doing that someday too. :) >> >> A couple suggestions: >> >> * Injection of MongoDB database instance using @Inject or some other >> annotation. >> * Type coercions from MongoDB object to JSONObject and vice-versa. >> >> -- >> Thiago H. de Paula Figueiredo >> >> >> - >> 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 > > - > 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: ProgressiveDisplay update parameter
FlowLogix library has a mixin that you can put into the layout component that controls and/or disable highlights. On Aug 15, 2012, at 12:41 PM, Dusko Jovanovski wrote: > Well, I'm trying to turn off the default yellow highlight with the symbol. > I filed a JIRA (https://issues.apache.org/jira/browse/TAP5-1987) since it's > a really easy fix. > > On Wed, Aug 15, 2012 at 7:28 PM, Howard Lewis Ship wrote: > >> You can add it to JIRA, but in 5.4, Tapestry is getting out of the >> client-side animation business. >> >> The pattern in 5.4 is that components will fire DOM events describing >> what's going on and, if you want, you can have a listener on the >> element, or a global listener on the body, provide the necessary UI >> animation. >> >> I've found in most applications that I've written that I ended up >> turning off the animations anyway. >> >> On Wed, Aug 15, 2012 at 9:59 AM, Dusko Jovanovski >> wrote: >>> I like the zone component >>> symbols, ComponentParameterConstants.ZONE_SHOW_METHOD = >>> "tapestry.components.zone_show_method" >>> and ComponentParameterConstants.ZONE_UPDATE_METHOD = >>> "tapestry.components.zone_update_method", but I would expect the >>> ProgressiveDisplay to honor the same symbol as the Zone component, or >>> optionally another separate symbol for the update parameter. >>> >>> Dev list, JIRA worthy or expected behaviour? >> >> >> >> -- >> 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: META-INF/assets/ in 5.4
What about /tapestry-assets or /t5-assets ? On Jul 28, 2012, at 9:37 AM, Bob Harner wrote: > To correct myself, the more common conflict would be with top-level > /asset folders defined by existing Tapestry-based applications. Still, > that should be uncommon and not such a hard problem to get around. > > On Sat, Jul 28, 2012 at 9:36 AM, Bob Harner wrote: >> Wouldn't the simplest and cleanest approach be to have assets in >> /assets (top level)? I guess the only problem would be the VERY rare >> case of another servlet in the same war that also uses /assets, but >> that problem is easily overcome by setting a tapestry.assets.folder >> symbol (rarely needed) to something else. >> >> tapestry.assets.folder = "" .. the default for Tapestry 5.3 and earlier >> >> tapestry.assets.folder = "/assets" . the default for Tapestry 5.4 and >> later >> >> tapestry.assets.folder = "/myass" . setting a custom location (rarely >> used) >> >> On Fri, Jul 27, 2012 at 1:56 PM, Massimo Lusetti wrote: >>> On Fri, Jul 27, 2012 at 7:26 PM, Howard Lewis Ship wrote: >>> In any case, the question is where to put the files; I'm open to META-INF/assets/ or T5-RESOURCES/assets/ or META-INF/tapestry/assets/ or TAPESTRY/assets/ or something along those lines. >>> >>> I'm not an expert or have enough experience but I would make then into >>> T5-RESOURCES/assets or something along the way as META-INF somehow >>> seems a stretch. >>> >>> 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 >>> > > - > 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
