Re: [VOTE] 5.4.2
Lance S. +1 (non-binding) On 10 Apr 2017 12:19, "Jochen Kemnade" wrote: > I've created and uploaded a release of Tapestry 5.4.2, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > > https://repository.apache.org/content/repositories/staging/ > org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.4.2, is > ready. > > I've also created a 5.4.2 tag in Git: > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a= > log;h=refs/tags/5.4.2 > > Vote will run for three days and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). >
Re: Getting ready for 5.4.2
There's a typescript gradle plugin https://github.com/sothmann/typescript-gradle-plugin The Tapestry build could use this at build time to convert Typescript to Javascript which is published to maven central. So downstream consumers wouldn't need nodejs installed On 4 Apr 2017 12:13 p.m., "Jochen Kemnade" wrote: > Hi, > > Am 04.04.2017 um 13:05 schrieb Bob Harner: > >> As I understand it the Typescript compiler is written Typescript, which >> can >> be compiled to JavaScript, and then that compiled compiler can be run in >> any compliant JavaScript engine, including Rhino that Tapestry already >> employs as well as the Nashorn engine built into Java 8. >> > > Not if they use Node API, for example for file access etc. But even if > they do that, there are ways to get it to work. You could rely on Node > being available on the PATH and just execute it, which is what > tapestry-react [1] does. > Or you could install a Node distribution on the fly and use that. > > Jochen > > [1] https://github.com/eddyson-de/tapestry-react > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: [VOTE] 5.4-rc-1
Lance S: +1 (non-binding) On 27 Oct 2015 18:11, "Kalle Korhonen" wrote: > Kalle Korhonen: +1 (non-binding) > > On Tue, Oct 27, 2015 at 10:25 AM, Jochen Kemnade > wrote: > > > Jochen Kemnade: +1 (binding) > > > > Jochen Kemnade schrieb am Mo., 26. Okt. 2015 um > > 18:28 Uhr: > > > > > Hi, > > > > > > I've created and uploaded a release of Tapestry 5.4-rc-1, ready to be > > > voted upon. > > > > > > The source and binary downloads are uploaded to: > > > > > > https://dist.apache.org/repos/dist/dev/tapestry > > > > > > and the Maven artifacts staged to: > > > > > > https://repository.apache.org/content/repositories/staging > > > > > > Please examine these files to determine if the new release, 5.4-rc-1, > > > is ready. > > > > > > I've also created a 5.4-rc-1 tag in Git: > > > > > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.4-rc-1 > > > > > > Vote will run for three days at least; On a successful vote, I'll > > > release the Maven artifacts, and move the source and javadoc > > > distributions from these directories to the proper distribution > > > directories and update the Tapestry site documentation, and send out > > > appropriate notifications. > > > > > > Jochen > > > > > > > > > > > > > > >
Re: [VOTE] 5.4-beta-35
Lance S: +1 (non-binding) On 19 Aug 2015 00:42, "Kalle Korhonen" wrote: > Kalle Korhonen: +1 (non-binding) > > On Tue, Aug 18, 2015 at 2:12 PM, françois facon > wrote: > > > François Facon: +1 (non binding) > > > > 2015-08-18 20:44 GMT+02:00 Dimitris Zenios : > > > > > +1 (non binding) > > > > > > On Tue, Aug 18, 2015 at 9:23 PM, Howard Lewis Ship > > > wrote: > > > > > > > Howard M. Lewis Ship: +1 (binding) > > > > > > > > On Tue, Aug 18, 2015 at 10:32 AM, Andreas Ernst > > wrote: > > > > > > > > > Andreas Ernst: +1 (non-binding) > > > > > > > > > > Am 18.08.15 um 18:33 schrieb Jochen Kemnade: > > > > > > > > > > Hi, > > > > >> > > > > >> I've created and uploaded a release of Tapestry 5.4-beta-35, ready > > to > > > be > > > > >> voted upon. > > > > >> > > > > >> The source and binary downloads are uploaded to: > > > > >> > > > > >> https://dist.apache.org/repos/dist/dev/tapestry > > > > >> > > > > >> and the Maven artifacts staged to: > > > > >> > > > > >> https://repository.apache.org/content/repositories/staging > > > > >> > > > > >> Please examine these files to determine if the new release, > > > 5.4-beta-35, > > > > >> is ready. > > > > >> > > > > >> I've also created a 5.4-beta-35 tag in Git: > > > > >> > > > > >> > > > > >> > > > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.4-beta-35 > > > > >> > > > > >> Vote will run for three days at least; On a successful vote, I'll > > > > >> release the Maven artifacts, and move the source and javadoc > > > > >> distributions from these directories to the proper distribution > > > > >> directories and update the Tapestry site documentation, and send > out > > > > >> appropriate notifications. > > > > >> > > > > >> Jochen > > > > >> > > > > >> > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > -- > > > > Howard M. Lewis Ship > > > > > > > > Looking for Clojure engagements: coding, architecture, mentoring & > > more! > > > > > > > > Creator of Apache Tapestry > > > > > > > > (971) 678-5210 > > > > http://howardlewisship.com > > > > @hlship > > > > > > > > > >
Re: Update ASM before 5.4 final?
Apart from repackaging... Is there anything special we do with ASM? Perhaps we could automate this using jarjar or shadow gradle plugins? On 12 Aug 2015 11:34, "Jochen Kemnade" wrote: > Hi, > > currently, we ship ASM 5.0.1 with plastic, the latest version is 5.0.4: > http://asm.ow2.org/history.html. As the 5.4 release seems to be coming > close (yeah!), I'd like to get that up-to-date. > What's the current way to update the sources? Is it a completely manual > process, as in download the tgz, extract the relevant part from the archive > and sed the package statement? > > Jochen > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: [Vote] Switch to release candidate
Lance S. +1 (non-binding) On 13 Jul 2015 20:53, "Thiago H de Paula Figueiredo" wrote: > Hi! > > I've fixed a couple of issues I considered showstoppers. 5.4 is long > overdue, and if not perfect, nothing remaining (to my view) can't wait for > a 5.4.1 or even a 5.5 (which, I would hope, we be months out, not years!). > > I would like the next tapestry release (not yet generated) to be rc-1. As > per our procedures, we have a binding vote to switch from beta to rc, then > a new standard vote for a public release. > > Vote to run for three days. I believe we need at least 3 +1's from PMC > members, and no -1's. > > Thiago H. de Paula Figueiredo: +1 (binding) > > -- > 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 > >
Re: [VOTE] Switch to release candidate
Lance S +1 (non-binding)
Re: What if … just jQuery?
I'm ok with using jquery directly, it would be interesting to know if anyone is actually using 5.4 + prototype (I doubt it). The good thing about jquery, compared to prototype, is that it doesn't pollute existing javascript objects (eg string). jquery is 35kb minified/gzipped, if people want to use a different 'foundation' framework than jquery, I doubt the extra 35kb is a deal breaker to have both in use.
Re: VOTE: Jochen Kemnade as PMC member
Lance S +1 (non-binding) On 27 Feb 2015 00:38, "Howard Lewis Ship" wrote: > If you haven't been noticing, Jochen has been putting in a lot of time on > Tapestry; closing bugs, leading discussions, and mentoring people on the > mailing list. He's been at it a more than long enough to show real > commitment ... I'd love to see someone this charged up added to the > Tapestry PMC. > > This is a binding vote to run for three days. It requires majority > approval: at least three binding +1's and more binding +1's than -1's. > > Howard M. Lewis Ship: +1 (binding) > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > @hlship >
Re: BeanModel and Commons package
Educated stab in the dark here but does ClasspathScannerImpl assume each package is contained within a single jar? I'm guessing Thiago's changes involved splitting a single package across 2 (maybe 3) jars to maintain backwards compatibility. On 23 Dec 2014 23:00, "Howard Lewis Ship" wrote: > I'm doing a build of latest, currently. Seeing one oddity: > > ioc.specs.ClasspathScannerImplSpec > can locate classes inside a > subpackage, inside an extracted JAR file FAILED > org.spockframework.runtime.ConditionNotSatisfiedError at > ClasspathScannerImplSpec.groovy:40 > > 708 tests completed, 1 failed, 2 skipped > :tapestry-ioc:test FAILED > > Off to investigate. > > On Mon, Dec 22, 2014 at 5:12 AM, Jochen Kemnade wrote: > > > I have to admit that I didn't have a chance to look into the changes you > > made yet, and probably, I won't get to doing that until 2015. > > But a new beta would be a good way to make more people (including me) > give > > them a try in the near future, so I'd say, just go ahead. :-) > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > @hlship >
Re: [VOTE] Tapestry Release 5.3.8
Lance S: +1 (non-binding) On 20 Nov 2014 19:21, "Kalle Korhonen" wrote: > I've created and uploaded a release of Tapestry 5.3.8, ready to be voted > upon. > > The source and source downloads are uploaded to: > http://people.apache.org/~kaosko/tapestry-releases/ > > and the Maven artifacts staged to: > > https://repository.apache.org/content/repositories/orgapachetapestry-1035 > > Please examine these files to determine if the new release, 5.3.8, is > ready. > > I've also created a 5.3.8 tag in Git: > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=shortlog;h=refs/tags/ > 5.3.8 > > Release notes page has been updated too. > > Vote will run for three days; On a successful vote, I'll release the Maven > artifacts, and move the source and javadoc distributions from these > directories > to the proper distribution directories and update the Tapestry site > documentation, and send out appropriate notifications. > > > Kalle Korhonen: +1 (non-binding) >
Re: BeanModel classes as a separate project and/or JAR?
Yes... It would be a dependency rather than the same package. Either way it's the same net result (tapestry-ioc on the classpath when all you wanted was a bean mapper). That's the bloatware I was speaking of. On 9 Oct 2014 22:19, "Thiago H de Paula Figueiredo" wrote: > On Thu, 09 Oct 2014 10:42:48 -0300, Lance Java > wrote: > > For a BeanModel framework to come packaged with tapestry-ioc feels like >> bloatware to me. >> > > I suggested a BeanModel JAR with a dependency on Tapestry-IoC, not > including Tapestry-IoC, in case we cannot really make a standalone > BeanModel JAR. > > -- > 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 > >
Re: BeanModel classes as a separate project and/or JAR?
On the other hand, the alternative of needing a "tapestry-commons" project isn't great either. On 9 Oct 2014 14:42, "Lance Java" wrote: > For a BeanModel framework to come packaged with tapestry-ioc feels like > bloatware to me. >
Re: BeanModel classes as a separate project and/or JAR?
For a BeanModel framework to come packaged with tapestry-ioc feels like bloatware to me.
Re: BeanModel classes as a separate project and/or JAR?
Sounds useful. I'm assuming plastic would need to be on the classpath but tapestry-ioc would not?
Re: REVOTE: Apache Tapestry 5.4-beta-22
Lance S: +1 (non-binding) On 2 Oct 2014 15:26, "Howard Lewis Ship" wrote: Since the last vote was actually a fail (not enough binding +1 votes), let's do a re-vote to make it official that beta-22 is properly endorsed as a beta release by the Tapestry PMC. Howard M. Lewis Ship: +1 (binding) -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com @hlship
Re: [VOTE] Apache Tapestry 5.4-beta-22
Lance S. +1 (non-binding) On 12 Sep 2014 23:36, "Howard Lewis Ship" wrote: > The perfect is the enemy of the good. It's been too long since the last > beta ... and I'd love to get a GA out this year. I had originally hoped for > last December! > > On Fri, Sep 12, 2014 at 10:54 AM, Jochen Kemnade > wrote: > > > Yes, you're right, we can do another beta every time we like, I just > have a > > slightly bad feeling about releasing a *public* beta that we know has a > bug > > that we already have a fix for. But I agree, it's nothing that > necessarily > > has to prevent a release, that's why I voted +0. > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > @hlship >
Re: [VOTE] Apache Tapestry 5.4-beta-17
Lance S: +1 (non-binding) On 2 Sep 2014 20:19, "Howard Lewis Ship" wrote: > I've created and uploaded a release of Tapestry 5.4-beta-17, ready to be > voted upon. > > The source and source downloads are uploaded to: > > http://people.apache.org/~hlship/tapestry-releases/ > > and the Maven artifacts staged to: > > https://repository.apache.org/content/repositories/staging/ > > Please examine these files to determine if the new release, 5.4-beta-17, is > ready. > > I've also created a 5.4-beta-17 tag in Git: > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=90e9bccb2cd3ebc8b502bee0bfc2aa03d11d9ba7 > > Vote will run for three days; On a successful vote, I'll release the Maven > artifacts, and move the source and javadoc distributions from these > directories > to the proper distribution directories and update the Tapestry site > documentation, and send out appropriate notifications. > > > Howard M. Lewis Ship: +1 (binding) > > > > P.S. This is the current release notes from JIRA: > > > Release Notes - Tapestry 5 - Version 5.4 > > > > > ** Bug > * [TAP5-311] - NPE in BeanDisplay if used in a form with a default > model > * [TAP5-736] - TextField validate parameter allows Null, but throws NPE > * [TAP5-773] - Select component should have parameter to allow option > labels to be rendered w/o HTML entity escaping > * [TAP5-800] - Server side error during provideCompletions event for > Autocompleter mixin is not reported on the client side properly > * [TAP5-805] - DateField does not allow disabling of client-side > validation, side-effects > * [TAP5-860] - JavaScript errors when adding validations to checkboxes > * [TAP5-901] - Generics return wrong type when subclassing page > * [TAP5-983] - CLONE -NPE in BeanDisplay if used in a form with a > default model > * [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-1010] - Fix Finnish validation message translation - corrected > file attached > * [TAP5-1066] - Client-Id and Links in Grid not correct when putting a > Grid inside a Loop > * [TAP5-1193] - tapestry.js prevents using the back/forward browser > cache > * [TAP5-1200] - Nested Ajax calls result in a call to $T(null) > * [TAP5-1305] - Service decorations can fail if using the conventional > naming > * [TAP5-1480] - Couldn't create property conduits for generic > interfaces > * [TAP5-1493] - Property expressions on properties that are covariant > on a base class use the type of the base class property, not the covariant > subclass > * [TAP5-1548] - Property expressions fails when using a supertype that > implements an interface with a matching method > * [TAP5-1569] - Grid should implement the ClientElement interface > * [TAP5-1601] - Sometime a method that references a field with a > conduit will not be instrumented, resulting in an NPE accessing the field > itself > * [TAP5-1658] - Submit context does not work inside Grid > * [TAP5-1668] - JavaDoc for @Parameter.value() should be clearer about > the empty string > * [TAP5-1672] - PropertyDisplay component will swallow NPEs when > evaluating the property, leaving no clue about the actual NPE > * [TAP5-1689] - Grid pagination details should be overridable via a > Grid parameter to support Grids that render in loops > * [TAP5-1691] - AssetPathConstructorImpl should URL-encode the > application version > * [TAP5-1704] - Localizing the "Today" and "None" labels in the core > datefield component > * [TAP5-1729] - Sometimes YUICompressor can fail with > java.util.EmptyStackException > * [TAP5-1730] - Ajax Zone is improperly reloaded when a mixin submits > form via JavaScript > * [TAP5-1734] - Race condition loading JavaScript libraries with > ProgressiveDisplay > * [TAP5-1735] - Most packages lack package-level javadocs > * [TAP5-1736] - Overriding a base class abstract event handler method > causes the sub-class method to be invoked twice > * [TAP5-1741] - Parsing template which contains Chinese (Maybe other > double bytes) words throws MalformedByteSequenceException: Invalid byte 3 > of 3-byte UTF-8 sequence. > * [TAP5-1742] - AfterRender() in Loop component should not short > circuit > * [TAP5-1744] - Returning a StreamPageContent instance from any of a > Form's events results in "Form components may not be placed inside other > Form components" exception > * [TAP5-1752] - Component cannot receive any event in a case when > transformer added event handler before OnEventWorker > * [TAP5-1762] - Some components do not have include a description of > their parameters in their JavaDoc pages > * [TAP5-1765] - PerThread scope is not honored when service is created > using autobuild > * [TAP5-1768] - @ActivationRequestParameter does not encode to be URL > friendly > * [TAP5-1769] - Form submitted with an aj
Re: Rename tapestry-ioc to hivemind
Ok, I'll have to admit defeat and let the ambiguity continue... ;) On 21 Jul 2014 17:08, "Howard Lewis Ship" wrote: > I think Thiago's summary ... that tapestry-ioc is five years old, so > renaming it will cause more confusion than good, is right on the money. I > would not support a rename. > > > On Mon, Jul 21, 2014 at 6:51 AM, Thiago H de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > On Mon, 21 Jul 2014 10:46:00 -0300, Lance Java < > lance.j...@googlemail.com> > > wrote: > > > > How's about tapioca as a name suggestion? It has references to tapestry > >> and ioc. :) > >> > > > > That's making me hungry and it's not lunch time here yet! :D > > > > A quick Google search for "tapioca framework" shows a number of existing > > stuff with that name, though, even a Java IoC framework: > > http://code.google.com/p/tapioca/. > > > > > > -- > > 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 > > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > @hlship >
Re: Rename tapestry-ioc to hivemind
How's about tapioca as a name suggestion? It has references to tapestry and ioc. :) On 21 Jul 2014 14:38, "Thiago H de Paula Figueiredo" wrote: > On Sat, 19 Jul 2014 05:02:28 -0300, Lance Java > wrote: > > I asked this question before I was a committer and generally got good >> feedback but it never really went anywhere. >> >> I think having tapestry-ioc and tapestry (the web framework) is a bit >> confusing. I also feel that it hinders the promotion / adoption of >> tapestry-ioc as a standalone product. >> > > I'm not sure what to think about this. Mixed feelings. I've posted before > that it would have been better for Tapestry-IoC for it to not have > 'Tapestry' in its name and Howard agreed. But, now, I'm not sure a rename > would do more harm or good. Tapestry 5, both web framework and IoC, had its > first final release in April 12, 2009, five years ago. There's already lots > of documentation and blog posts and etc about it, so a rename for avoiding > confusion would end up causing more confusion of its own. > > I agree with Bob about not ressurecting old product names. It would add > more confusion. HiveMind was XML-heavy, and Tapestry-IoC is XML-free. Maybe > Tapestry 5 itself shouldn't have been named Tapestry, for the same reason, > as it was a rewrite for scratch. > > Regarding the development cycle, I don't think right now it's a speed bump > for Tapestry-IoC. As an IoC core (kernel?), it's a mature product. Its last > major change I could remember was the copying of service implementation > annotations to the corresponding service proxies. Before that, live class > reloading for service implementations and JSR 303's @Inject support. I > guess the features Tapestry-IoC would most benefit from now on don't need > changes in itself, but additional packages that integrate it with other > stuff. Of course, other people may see things differently, and I love to > discuss it. > > Summary: I wish Tapestry-IoC had another name and that it wasn't HiveMind > (maybe Collective?), but IMHO it's too late to rename it, even if I think > discussing it is a very good thing. > > -- > 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 > >
Re: Rename tapestry-ioc to hivemind
As discussed, I'm not suggesting to move the project outside of the tapestry build / release. I'm also not tied to the hivemind name. I constantly find myself saying tapestry (the web framework) and tapestry-ioc on the user's list. A rename would help remove this ambiguity. On 21 Jul 2014 11:42, "Bob Harner" wrote: > I don't think it's a good idea to resurrect old software product names, > because you bring with them all the old connotations. To the extent people > know about Hivemind, they think of the product as old, out of date & dead. > > Also, there were good reasons why Tapestry-IOC was not treated as a > distinct project. As our docs say: "The difficulty of managing the release > schedules of two complex frameworks proved to be an issue." > On Jul 21, 2014 3:22 AM, "Jochen Kemnade" > wrote: > > > Hi, > > > > Am 19.07.2014 10:02, schrieb Lance Java: > > > >> I think having tapestry-ioc and tapestry (the web framework) is a bit > >> confusing. I also feel that it hinders the promotion / adoption of > >> tapestry-ioc as a standalone product. > >> > > > > I see your point. I don't really have a strong opinion about that matter, > > but here we go. > > > > 1. Do you agree that tapestry-ioc should be renamed? > >> > > > > No. That's in terms of "should", not "could". I'm not against a rename, I > > just don't think it's necessary. > > > > 2. Do you think it should be called hivemind? > >> > > > > No. I also think that the name hivemind is taken and we shouldn't > > resurrect it. People would probably start to dig out old documentation > and > > mailing list threads. > > > > 3. Do you have an alternative name? > >> > > > > What about something with a relation to the word "tapestry"? Something > > like cotton, cloth, fabric (hm, I like that one, but there's at least > > http://www.fabfile.org/ and http://dev.mysql.com/downloads/fabric/). > > > > 4. Should a rename be done as part of 5.4 or 5.5? > >> > > > > I assume that's an XOR. ;-) I guess it depends on how thorough we want > the > > change to be. Do we also want to rename all the packages and classes with > > "IOC" in them? Then we'd probably even have to wait for 6.0. If it's just > > the name and the documentation, I think we could do it for 5.4. > > > > Jochen > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: dev-h...@tapestry.apache.org > > > > >
Re: Rename tapestry-ioc to hivemind
Hi Dimitris, I'm not (at this stage) suggesting to move tapestry-ioc outside of the tapestry build / release. I'm just suggesting a rename at the moment and it can live inside the tapestry build, similar to plastic. On 19 Jul 2014 09:11, "Dimitris Zenios" wrote: > I use tapestry-ioc in many projects outside of tapestry web framework. > > I agree that it should be taken out of the tapestry-web and form its own > project. > > > On Sat, Jul 19, 2014 at 11:02 AM, Lance Java > wrote: > > > I asked this question before I was a committer and generally got good > > feedback but it never really went anywhere. > > > > I think having tapestry-ioc and tapestry (the web framework) is a bit > > confusing. I also feel that it hinders the promotion / adoption of > > tapestry-ioc as a standalone product. > > > > So, I have some questions to consider. > > 1. Do you agree that tapestry-ioc should be renamed? > > 2. Do you think it should be called hivemind? > > 3. Do you have an alternative name? > > 4. Should a rename be done as part of 5.4 or 5.5? > > > > If the feedback to this thread forms a general consensus, I'll put it to > a > > proper vote. > > > > Lance. > > >
Rename tapestry-ioc to hivemind
I asked this question before I was a committer and generally got good feedback but it never really went anywhere. I think having tapestry-ioc and tapestry (the web framework) is a bit confusing. I also feel that it hinders the promotion / adoption of tapestry-ioc as a standalone product. So, I have some questions to consider. 1. Do you agree that tapestry-ioc should be renamed? 2. Do you think it should be called hivemind? 3. Do you have an alternative name? 4. Should a rename be done as part of 5.4 or 5.5? If the feedback to this thread forms a general consensus, I'll put it to a proper vote. Lance.
Re: Abandon java.beans.Introspector or keep working around it?
Yeah, I must say I thinking the same thing. It's not rocket science what the introspector is doing. We could support isX() for java.lang.Boolean too if we had our own introspector. On 28 Jun 2014 13:54, "Thiago H de Paula Figueiredo" wrote: > Hi! > > While investigating TAP5-1548 and TAP5-1885 and also reading TAP5-921 I > reached the conclusion that Introspector isn't finding all the properties > in some circustances, specially when the getter is defined in one type and > the setter in another one in the class hierarchy. The tickets have > examples. What do you guys think about ditching its use? Or do you think we > should work around it? > > Meanwhile, I'm trying a workaround. > > 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 > >
Re: TAP5-1213: Changes to public API
Haha... I could try / catch AbstractMethodError and get rid of Binding2 / PropertyConduit2. Win! Jokes... On 20 May 2014 17:46, "Jochen Kemnade" wrote: > True, but if they occur, the cause is not so easy to find IMO. >
Re: TAP5-1213: Changes to public API
I was referring to the exception being rare, not third party implementations. Keep in mind that the exception will only occur when invoking the new method on ComponentResources. At the moment there is no such code in existence. On 20 May 2014 13:51, "Thiago H de Paula Figueiredo" wrote: > On Tue, 20 May 2014 07:20:21 -0300, Lance Java > wrote: > > This would only occur in third party bindings / propertyConduits that >> don't extend core (internal) implementations. >> >> IMHO these exceptions are likely to be rare as hen's teeth ;) >> > > Agreed for ComponentResources, less agreed for Binding and disagreed for > PropertyConduit, which is used inside some projects to implement some > properties for BeanModel-based components. This is *not* uncommon to be > found in non-library code. > > -- > 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 > >
Re: TAP5-1213: Changes to public API
> wouldn't adding methods to the existing interfaces lead to libraries written for (and compiled against) Tapestry 5.3 would not work with Tapestry 5.4 anymore? In this instance, I would assume an AbstractMethodError would be thrown when calling the new method: ComponentResources.getBoundGenericType(paramName) This would only occur in third party bindings / propertyConduits that don't extend core (internal) implementations. IMHO these exceptions are likely to be rare as hen's teeth ;)
Re: tapestry-ioc & java 8
Tapestry has switched to plastic for its byte code magic. Currently,
plastic isn't well documented. I find that the best documentation currently
is the test cases. Perhaps you can find your answer here:
https://github.com/apache/tapestry-5/tree/master/plastic/src/test/groovy/org/apache/tapestry5/plastic
On 19 May 2014 23:46, "Jigar Joshi" wrote:
> Hello
>
> with tapestry 5.3.4 and java 7 with use of
> org.apache.tapestry5.ioc.services.ClassFactory
>
>
>
> private Class createProxyClass(ServiceResources resources) {
> Class serviceInterface = resources.getServiceInterface();
>
> ClassFab cf = classFactory.newClass(serviceInterface);
>
> // add field
> cf.addField("_creator", Modifier.PRIVATE | Modifier.FINAL,
> SomeClass.class);
>
> // Constructor takes a ServiceCreator
> cf.addConstructor(new Class[] { SomeClass.class }, null, "_creator
> = $1;");
>
> // add method
> String body = format("return (%s) _creator.get();",
> serviceInterface.getName());
> MethodSignature sig = new MethodSignature(serviceInterface,
> SCOPE_METHOD_NAME, null, null);
> cf.addMethod(Modifier.PRIVATE, sig, body);
> String toString = format("",
> scope, resources.getServiceId(),
> serviceInterface.getName());
>
> cf.proxyMethodsToDelegate(serviceInterface, SCOPE_METHOD_NAME +
> "()", toString);
>
> return cf.createClass();
> }
>
>
>
>
>
> with tapestry 5.4-beta3 this class has been removed (it was depricated)
>
> I played around a little bit to find related implementation in new replaced
> class
>
> org.apache.tapestry5.ioc.services.PlasticProxyFactory
>
> couldn't find it offhand, how to achieve same thing with tapestry 5.4 ?
>
> Thanks!
> Jigar
>
Re: TAP5-1213: Changes to public API
I agree but thought I was in the minority. The extra interfaces have increased the complexity and require third parties to know about the nuances of the implementation. Adding methods to the public API may cause compilation errors (in rare cases) but at least it's clear. Anyone else have an opinion? On 20 May 2014 00:13, "Kalle Korhonen" wrote: > JMHO, maintaining backwards compatibility in this case isn't worth the > added complexity. Making support libraries compatible requires just > compiling them against the new version and there are many other, more > drastic changes in 5.4 that require at least a re-compilation and in many > cases, changes in the library code. Just my point of view as an author of > multiple T5.4 support libraries. > > Kalle > > > On Mon, May 19, 2014 at 1:52 PM, Lance Java >wrote: > > > ok, just committed with Binding2 / PropertyConduit2 keeping backwards > > compatibility in tact. > > > > > > On 19 May 2014 19:02, Lance Java wrote: > > > > > I can implement like that if others agree. I just hate instanceof > > littered > > > around the place. > > > > > > It also brings up the possibility of third parties wrapping a Binding2 > > > with a Binding and losing functionality. I'd prefer a compilation error > > > myself. > > > On 19 May 2014 17:46, "Thiago H de Paula Figueiredo" < > > thiag...@gmail.com> > > > wrote: > > > > > >> On Mon, 19 May 2014 13:04:55 -0300, Lance Java < > > lance.j...@googlemail.com> > > >> wrote: > > >> > > >> I guess my question is, is it worth adding / maintaining Binding2 and > > >>> PropertyConduit2 and all the type checking / adapting. > > >>> > > >>> Or are we happy to add the methods to the public API given its a no > > >>> brainer to implement getGenericType() to return getType() > > >>> > > >> > > >> Considering we've dealt with this kind of scenario using the first > > option > > >> (Binding2 and PropertyConduit2), I'd go with it. I guess just a > handful > > of > > >> places would need to be adapted. > > >> > > >> -- > > >> 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 > > >> > > >> > > >
Re: TAP5-1213: Changes to public API
ok, just committed with Binding2 / PropertyConduit2 keeping backwards compatibility in tact. On 19 May 2014 19:02, Lance Java wrote: > I can implement like that if others agree. I just hate instanceof littered > around the place. > > It also brings up the possibility of third parties wrapping a Binding2 > with a Binding and losing functionality. I'd prefer a compilation error > myself. > On 19 May 2014 17:46, "Thiago H de Paula Figueiredo" > wrote: > >> On Mon, 19 May 2014 13:04:55 -0300, Lance Java >> wrote: >> >> I guess my question is, is it worth adding / maintaining Binding2 and >>> PropertyConduit2 and all the type checking / adapting. >>> >>> Or are we happy to add the methods to the public API given its a no >>> brainer to implement getGenericType() to return getType() >>> >> >> Considering we've dealt with this kind of scenario using the first option >> (Binding2 and PropertyConduit2), I'd go with it. I guess just a handful of >> places would need to be adapted. >> >> -- >> 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 >> >>
Re: TAP5-1213: Changes to public API
I can implement like that if others agree. I just hate instanceof littered around the place. It also brings up the possibility of third parties wrapping a Binding2 with a Binding and losing functionality. I'd prefer a compilation error myself. On 19 May 2014 17:46, "Thiago H de Paula Figueiredo" wrote: > On Mon, 19 May 2014 13:04:55 -0300, Lance Java > wrote: > > I guess my question is, is it worth adding / maintaining Binding2 and >> PropertyConduit2 and all the type checking / adapting. >> >> Or are we happy to add the methods to the public API given its a no >> brainer to implement getGenericType() to return getType() >> > > Considering we've dealt with this kind of scenario using the first option > (Binding2 and PropertyConduit2), I'd go with it. I guess just a handful of > places would need to be adapted. > > -- > 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 > >
Re: TAP5-1213: Changes to public API
I guess my question is, is it worth adding / maintaining Binding2 and PropertyConduit2 and all the type checking / adapting. Or are we happy to add the methods to the public API given its a no brainer to implement getGenericType() to return getType() On 19 May 2014 15:17, "Thiago H de Paula Figueiredo" wrote: > On Sat, 17 May 2014 14:27:21 -0300, Lance Java > wrote: > > I don't think anyone will be implementing their own ComponentResources or >> PropertyConduit so I think those changes are fin. >> > > Agreed with ComponentResources, not about PropertyConduit, but I still > think that wouldn't be a problem, specially if a new PropertyConduit2 > interface is defined. > > -- > 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 > >
Re: [VOTE] Drop support for Java 5 in Tapestry 5.4 (2nd attempt)
Lance Semmens +0 (non-binding) I can't really see much benefit but I won't stand in the way. On 18 May 2014 18:05, "Jochen Kemnade" wrote: > There have been discussions whether we want to keep compatibility with > Java 5 for the upcoming 5.4 release. > Java 5 is EOSL since October 2009. > While requiring Java 6 would not bring us much benefits, there might be > some libraries that we cannot use because they do not support Java 5. > Also, we'd spare ourselves some efforts not having to support Java 5 > anymore. > The vote will run for 3 days and, if it succeeds, I will increase the > minimum required Java version to 1.6. > > Jochen Kemnade: +1 (non-binding) > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > >
Re: TAP5-1213: Changes to public API
I've uploaded the patch to jira https://issues.apache.org/jira/browse/TAP5-1213 https://issues.apache.org/jira/secure/attachment/12645469/TAP5-1213.patch Cheers, Lance. On 18 May 2014 16:49, Ulrich Stärk wrote: > If you are unsure you can send the patch here and ask for reviews. > > Uli > > On 2014-05-18 16:39, Lance Java wrote: > > So, is it OK to commit the changes? It will obviously need a breaking > > change note in the release notes. > > On 18 May 2014 00:10, "Howard Lewis Ship" wrote: > > > >> It can be problematic; I don't expect people to implement > >> ComponentResources ... but some other common interfaces, such as > >> FormSupport, are often proxied/delegated in a way that provides pain > when > >> new methods are added. JDK 8 default methods may help there, hard to > say > >> so far. > >> > >> > >> On Sat, May 17, 2014 at 1:27 PM, Lance Java >>> wrote: > >> > >>> I've managed to solve the issue without affecting > >> org.apache.tapestry5.ioc. > >>> services.PropertyAdapter. > >>> > >>> So the introduced methods are: > >>> Type Binding.getBindingGenericType() > >>> Type PropertyConduit getPropertyGenericType() > >>> Type ComponentResources.getBoundGenericType(String parameterName) > >>> > >>> I don't think anyone will be implementing their own ComponentResources > or > >>> PropertyConduit so I think those changes are fin. Ashas been mentioned, > >>> third parties (including myself) have implemented custom bindings. If > >> it's > >>> any consolation, I've implemented > AbstractBinding.getBindingGenericType() > >>> to simply return getBindingType(). > >>> > >>> The other solution I can see is to have Binding2 in a similar style to > >>> Asset2 etc. > >>> > >>> > >>> On 16 May 2014 00:48, Howard Lewis Ship wrote: > >>> > >>>> I'd need to know a bit more; this will tend to break 3rd party > >> libraries > >>>> that compile against the old code, which is not so good. Possibly if > >> the > >>>> new information could be added under an entirely new method of the > >>> existing > >>>> APIs that would be less of a problem. > >>>> > >>>> > >>>> On Wed, May 14, 2014 at 1:33 PM, Lance Java < > lance.j...@googlemail.com > >>>>> wrote: > >>>> > >>>>> I'm looking into TAP5-1213 to provide access to the bound property's > >>>>> generic type information (eg List). Basically the generic > >>> type > >>>>> information needs to be passed from PropertyConduitSource to > >>>>> ComponentResources > >>>>> > >>>>> This change requires adding a generic type getter to a few public > >>>>> interfaces, namely: > >>>>> - org.apache.tapestry5.Binding > >>>>> - org.apache.tapestry5.ComponentResources > >>>>> - org.apache.tapestry5.PropertyConduit > >>>>> - org.apache.tapestry5.ioc.services.PropertyAdapter > >>>>> > >>>>> I realise that adding methods to public interfaces breaks backwards > >>>>> compatability. What's people's thoughts on this? > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Howard M. Lewis Ship > >>>> > >>>> Creator of Apache Tapestry > >>>> > >>>> The source for Tapestry training, mentoring and support. Contact me to > >>>> learn how I can get you up and productive in Tapestry fast! > >>>> > >>>> (971) 678-5210 > >>>> http://howardlewisship.com > >>>> @hlship > >>>> > >>> > >> > >> > >> > >> -- > >> Howard M. Lewis Ship > >> > >> Creator of Apache Tapestry > >> > >> The source for Tapestry training, mentoring and support. Contact me to > >> learn how I can get you up and productive in Tapestry fast! > >> > >> (971) 678-5210 > >> http://howardlewisship.com > >> @hlship > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: TAP5-1213: Changes to public API
So, is it OK to commit the changes? It will obviously need a breaking change note in the release notes. On 18 May 2014 00:10, "Howard Lewis Ship" wrote: > It can be problematic; I don't expect people to implement > ComponentResources ... but some other common interfaces, such as > FormSupport, are often proxied/delegated in a way that provides pain when > new methods are added. JDK 8 default methods may help there, hard to say > so far. > > > On Sat, May 17, 2014 at 1:27 PM, Lance Java >wrote: > > > I've managed to solve the issue without affecting > org.apache.tapestry5.ioc. > > services.PropertyAdapter. > > > > So the introduced methods are: > > Type Binding.getBindingGenericType() > > Type PropertyConduit getPropertyGenericType() > > Type ComponentResources.getBoundGenericType(String parameterName) > > > > I don't think anyone will be implementing their own ComponentResources or > > PropertyConduit so I think those changes are fin. Ashas been mentioned, > > third parties (including myself) have implemented custom bindings. If > it's > > any consolation, I've implemented AbstractBinding.getBindingGenericType() > > to simply return getBindingType(). > > > > The other solution I can see is to have Binding2 in a similar style to > > Asset2 etc. > > > > > > On 16 May 2014 00:48, Howard Lewis Ship wrote: > > > > > I'd need to know a bit more; this will tend to break 3rd party > libraries > > > that compile against the old code, which is not so good. Possibly if > the > > > new information could be added under an entirely new method of the > > existing > > > APIs that would be less of a problem. > > > > > > > > > On Wed, May 14, 2014 at 1:33 PM, Lance Java > > >wrote: > > > > > > > I'm looking into TAP5-1213 to provide access to the bound property's > > > > generic type information (eg List). Basically the generic > > type > > > > information needs to be passed from PropertyConduitSource to > > > > ComponentResources > > > > > > > > This change requires adding a generic type getter to a few public > > > > interfaces, namely: > > > > - org.apache.tapestry5.Binding > > > > - org.apache.tapestry5.ComponentResources > > > > - org.apache.tapestry5.PropertyConduit > > > > - org.apache.tapestry5.ioc.services.PropertyAdapter > > > > > > > > I realise that adding methods to public interfaces breaks backwards > > > > compatability. What's people's thoughts on this? > > > > > > > > > > > > > > > > -- > > > Howard M. Lewis Ship > > > > > > Creator of Apache Tapestry > > > > > > The source for Tapestry training, mentoring and support. Contact me to > > > learn how I can get you up and productive in Tapestry fast! > > > > > > (971) 678-5210 > > > http://howardlewisship.com > > > @hlship > > > > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > @hlship >
Re: TAP5-1213: Changes to public API
I've managed to solve the issue without affecting org.apache.tapestry5.ioc. services.PropertyAdapter. So the introduced methods are: Type Binding.getBindingGenericType() Type PropertyConduit getPropertyGenericType() Type ComponentResources.getBoundGenericType(String parameterName) I don't think anyone will be implementing their own ComponentResources or PropertyConduit so I think those changes are fin. Ashas been mentioned, third parties (including myself) have implemented custom bindings. If it's any consolation, I've implemented AbstractBinding.getBindingGenericType() to simply return getBindingType(). The other solution I can see is to have Binding2 in a similar style to Asset2 etc. On 16 May 2014 00:48, Howard Lewis Ship wrote: > I'd need to know a bit more; this will tend to break 3rd party libraries > that compile against the old code, which is not so good. Possibly if the > new information could be added under an entirely new method of the existing > APIs that would be less of a problem. > > > On Wed, May 14, 2014 at 1:33 PM, Lance Java >wrote: > > > I'm looking into TAP5-1213 to provide access to the bound property's > > generic type information (eg List). Basically the generic type > > information needs to be passed from PropertyConduitSource to > > ComponentResources > > > > This change requires adding a generic type getter to a few public > > interfaces, namely: > > - org.apache.tapestry5.Binding > > - org.apache.tapestry5.ComponentResources > > - org.apache.tapestry5.PropertyConduit > > - org.apache.tapestry5.ioc.services.PropertyAdapter > > > > I realise that adding methods to public interfaces breaks backwards > > compatability. What's people's thoughts on this? > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > @hlship >
Re: Wrong default types for validate/translate in AbstractTextField?
Hi Michael, in future... Please post to the user's mailing list. This list
is for the tapestry development team.
No, this is not a bug. Pages and components are singletons. Under the hood
they use bindings to get() and set() dynamic values at runtime. In this
instance the binding can get() a FieldTranslate instance at runtime.
You are probably more familiar with the prop: binding which can access a
property at runtime.
On 16 May 2014 18:02, "Michael Wyraz" wrote:
> Hi,
>
> I found something I do not understand and which is probably a bug. From
> org.apache.tapestry5.corelib.base.AbstractTextField:
>
> @Parameter(required = true, allowNull = false, defaultPrefix =
> BindingConstants.TRANSLATE)
> private FieldTranslator translate;
>
> @Parameter(defaultPrefix = BindingConstants.VALIDATE)
> @SuppressWarnings("unchecked")
> private FieldValidator validate;
>
> But the type of the default() methods differ:
>
> final Binding defaultTranslate()
> {
> return defaultProvider.defaultTranslatorBinding("value",
> resources);
> }
>
> final Binding defaultValidate()
> {
> return defaultProvider.defaultValidatorBinding("value",
> resources);
> }
>
> The interfaces "Binding" and "FieldTranslator" have nothing common. So I
> cannot imagine that (and how) this could work.
>
> Is it a bug?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>
TAP5-1213: Changes to public API
I'm looking into TAP5-1213 to provide access to the bound property's generic type information (eg List). Basically the generic type information needs to be passed from PropertyConduitSource to ComponentResources This change requires adding a generic type getter to a few public interfaces, namely: - org.apache.tapestry5.Binding - org.apache.tapestry5.ComponentResources - org.apache.tapestry5.PropertyConduit - org.apache.tapestry5.ioc.services.PropertyAdapter I realise that adding methods to public interfaces breaks backwards compatability. What's people's thoughts on this?
Re: Accessing generic type information of bound parameters
Just having a quick poke through the code this could be fixed by adding the following methods to the public API. java.lang.reflect.Type PropertyConduit.getPropertyGenericType() java.lang.reflect.Type Binding.getBindingGenericType() java.lang.reflect.Type ComponentResources.getBoundGenericType(String parameterName) I'm guessing that only PropBinding would return a type from getBindingGenericType(). All other bindings would return null.
Re: Accessing generic type information of bound parameters
> No, there is no way to access the generic type, this information is lost
during the compilation process.
That's not actually correct. Lets consider the following class:
public class MyClass {
private List foos;
public List getBars() {
...
}
public void doStuffWithBaz() {
List bazs = new ArrayList();
...
}
}
In this example, the ONLY generic that will be lost after compilation (due
to type erasure) is Baz. Both Foo and Bar ARE available at runtime.
@see
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Method.html#getGenericReturnType()
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#getGenericType()
Re: [VOTE] Jochen Kemnade as Tapestry Committer
Lance Semmens + 1 (non-binding) On 17 Apr 2014 22:41, "Howard Lewis Ship" wrote: > I've seen Jochen busy on the mailing list for quite some time, and even > busier filing bugs and submitting patches. I think he'd make a fine > addition to the team. > > Howard M. Lewis Ship: +1 (binding) > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > @hlship >
Re: Broken UTF-8 handling in tapestry 5.4 becomes show-stopper - please help
Ideally, it would all be driven by the encoding specified by the xml template. As a second choice, I think it should be driven by a configurable symbol.
Re: Broken UTF-8 handling in tapestry 5.4 becomes show-stopper - please help
> It still would be great if this could be fixed :-) Agreed, but I'm not convinced that hard coding UTF8 is the answer :)
Re: Broken UTF-8 handling in tapestry 5.4 becomes show-stopper - please help
You could set -Dfile.encoding=UTF-8 when starting up the servlet container. On 8 Apr 2014 14:24, "Michael Wyraz" wrote: > Hi, > > could please anyone with commit access fix this little issue > https://issues.apache.org/jira/browse/TAP5-2219 or at least add the > testcase to the testsuite? This becomes a show-stopper for us for migration > to tapestry 5.4 since all pages with utf-8 chars fails on windows. > > Kind regards, > Michael. > > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: WTF with the broken tests?
So sorry... I can appreciate that you're overstretched. I've removed :tapestry-ioc-test from the build so that the build can pass again I'll fix the test tonight (UK time). On 1 April 2014 23:40, Howard Lewis Ship wrote: > Please stop committing broken changes! > > It is extremely disrespectful to the other developers and their very full > schedules to commit code that is broken. Ok, it's very disrespectful to me > and my 150% over-taxed schedule. > > I've spent the last couple of hours fixing other people's bugs in the test > suites. > > I'm trying to generate a beta-4 release. > > Any idea what this is about? > > :tapestry-ioc-test:test > > org.apache.tapestry5.ioc.test.TapestryIOCJUnit4ClassRunnerAfterClassTest > > testInjectB FAILED > java.lang.AssertionError at > TapestryIOCJUnit4ClassRunnerAfterClassTest.java:51 > > 5 tests completed, 1 failed > :tapestry-ioc-test:test FAILED > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com >
Re: Jira Access
Thanks, all good now. On 1 Apr 2014 17:07, "Howard Lewis Ship" wrote: > You should be good to go. > > > On Tue, Apr 1, 2014 at 9:05 AM, Howard Lewis Ship > wrote: > > > I'll take care of it. > > > > > > On Tue, Apr 1, 2014 at 1:02 AM, Lance Java >wrote: > > > >> Hi Tapestry devs. I'm trying to assign a jira to myself but don't seem > to > >> have the privileges. Can someone please give me dev rights in jira? > >> Username = "Lance". > >> > >> Thanks. > >> > > > > > > > > -- > > 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 >
Jira Access
Hi Tapestry devs. I'm trying to assign a jira to myself but don't seem to have the privileges. Can someone please give me dev rights in jira? Username = "Lance". Thanks.
Re: Discussion on AJAX requests need even more than a context?
I realise what I'm saying is similar to your original suggestion
ajaxResponseRenderer.setQueryParameters("filter", filterValue);
In your suggestion, the value (filterValue) is known serverside. I think we
need the ability to pass a clientside value that the server may not know
about.
Let's think about things we might want to pass from client to server:
1. The current value of a field
2. The current location of the mouse
3. The size of the client's screen
4. A serverside value known at render time.
A future proof solution would allow a component to register a javascript
closure to be executed and the resultant value is sent to the server. A
default/builtin closure implementation can get the current value of a
clientside field.
On 27 Mar 2014 09:21, "Lance Java" wrote:
> Yes, you're right. You would need the current field values to be passed
> along with the submit. @Persist cookie would work.
>
> Or a mechanism like the onevent mixin would work where a list of field ids
> is required and passed from client to server. But as you said, you don't
> like this because one component needs knowledge of the other.
>
> If the list of fields was passed from the containing page (or component)
> I'm thinking it's ok. Perhaps each component could register it's fields
> with the container so it's more transparent?
> On 26 Mar 2014 00:49, "Geoff Callender" <
> geoff.callender.jumpst...@gmail.com> wrote:
>
>> Sorry, but I've read the solution below 10 times now and it hurts my head
>> every time! :-) I don't see how it gets around the problem that when E is
>> AJAX-submitted, the server-side elements can find ways to prod L to refresh
>> but they cannot tell L the current value of F. The server-side doesn't know
>> the current value of F, unless we make the server-side stateful (no thank
>> you), or we somehow include the value of F in every request.
>>
>> What I'm aiming for is a solution which works declaratively. You know,
>> where you don't see the plumbing. Just like @ActivationRequestParameter,
>> but at the component level.
>>
>> On 21/03/2014, at 2:35 AM, Lance Java wrote:
>>
>> > I'm imagining the pub sub would work like...
>> >
>> > public class L {
>> > @Inject
>> > private Publisher publisher;
>> >
>> > @Inject
>> > private Block someBlock;
>> >
>> > /**
>> > * Fired when the select menu changes
>> > */
>> > public Object onFilterChange(Entity entity) {
>> >publisher.publish("changeEntity", entity);
>> >return someBlock;
>> > }
>> > }
>> >
>> > public class E {
>> > @Inject
>> > private AjaxResponseRenderer ajaxResponseRenderer;
>> >
>> > @Inject
>> > private Zone someZone;
>> >
>> > @Property
>> > private Entity entity;
>> >
>> > @Subscribe(topic="changeEntity")
>> > void subscribeChangeEntity(Entity entity) {
>> > this.entity = entity;
>> > ajaxResponseRenderer.addRender(someZone;
>> > }
>> > }
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: dev-h...@tapestry.apache.org
>>
>>
Re: Discussion on AJAX requests need even more than a context?
Yes, you're right. You would need the current field values to be passed
along with the submit. @Persist cookie would work.
Or a mechanism like the onevent mixin would work where a list of field ids
is required and passed from client to server. But as you said, you don't
like this because one component needs knowledge of the other.
If the list of fields was passed from the containing page (or component)
I'm thinking it's ok. Perhaps each component could register it's fields
with the container so it's more transparent?
On 26 Mar 2014 00:49, "Geoff Callender"
wrote:
> Sorry, but I've read the solution below 10 times now and it hurts my head
> every time! :-) I don't see how it gets around the problem that when E is
> AJAX-submitted, the server-side elements can find ways to prod L to refresh
> but they cannot tell L the current value of F. The server-side doesn't know
> the current value of F, unless we make the server-side stateful (no thank
> you), or we somehow include the value of F in every request.
>
> What I'm aiming for is a solution which works declaratively. You know,
> where you don't see the plumbing. Just like @ActivationRequestParameter,
> but at the component level.
>
> On 21/03/2014, at 2:35 AM, Lance Java wrote:
>
> > I'm imagining the pub sub would work like...
> >
> > public class L {
> > @Inject
> > private Publisher publisher;
> >
> > @Inject
> > private Block someBlock;
> >
> > /**
> > * Fired when the select menu changes
> > */
> > public Object onFilterChange(Entity entity) {
> >publisher.publish("changeEntity", entity);
> >return someBlock;
> > }
> > }
> >
> > public class E {
> > @Inject
> > private AjaxResponseRenderer ajaxResponseRenderer;
> >
> > @Inject
> > private Zone someZone;
> >
> > @Property
> > private Entity entity;
> >
> > @Subscribe(topic="changeEntity")
> > void subscribeChangeEntity(Entity entity) {
> > this.entity = entity;
> > ajaxResponseRenderer.addRender(someZone;
> > }
> > }
>
>
> -
> 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
Can't jarjar or similar do this via byte code transform automatically as part of the build? On 21 Mar 2014 16:40, "Kalle Korhonen" wrote: > On Fri, Mar 21, 2014 at 3:57 AM, Bob Harner wrote: > > > Kalle, can you list the steps you went through to do this? I'd like to > > document the process, since it isn't simply a matter of incrementing the > > version of a dependency. > > > > Sure. It was very simple actually: > 1) Have plastic module open on your favorite IDE > 2) Download an asm source release from http://forge.ow2.org/projects/asm/ > 3) untar the asm source, move the source tree (starting from "org") next to > plastic/src/external/java > 4) delete the existing package "org.apache.tapestry5.internal.plastic.asm" > 5) use the IDE to rename the "org.objectweb.asm" package to > "org.apache.tapestry5.internal.plastic.asm" > 6) fix compilation errors > > Naturally, your IDE needs to be smart enough to refactor the package names > in the class files accordingly. > > Kalle > > > > > On Mar 20, 2014 4:16 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 < > li...@progs.be > > > >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 > > > > > > > > > > > > > >
Re: Discussion on AJAX requests need even more than a context?
I'm imagining the pub sub would work like...
public class L {
@Inject
private Publisher publisher;
@Inject
private Block someBlock;
/**
* Fired when the select menu changes
*/
public Object onFilterChange(Entity entity) {
publisher.publish("changeEntity", entity);
return someBlock;
}
}
public class E {
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Zone someZone;
@Property
private Entity entity;
@Subscribe(topic="changeEntity")
void subscribeChangeEntity(Entity entity) {
this.entity = entity;
ajaxResponseRenderer.addRender(someZone;
}
}
Re: Discussion on AJAX requests need even more than a context?
That's an interesting concept. I like the sound of it.
On 20 Mar 2014 09:22, "Nourredine K." wrote:
> Hi Geoff,
>
> Maybe the very interesting Dmitri's contribution can help here.
> It implements the publisher-subscriber pattern for Tapestry5
> pages/components.
>
> https://github.com/anjlab/anjlab-tapestry-commons/wiki/Publisher-API
>
> Nourredine.
>
>
> 2014-03-19 13:45 GMT+01:00 Geoff Callender <
> geoff.callender.jumpst...@gmail.com>:
>
> > So it seems we're pretty much agreed that each AJAX-capable component
> > needs a context parameter, which its containing component can use to
> > restore its state (usually its parameters) before it makes any decisions.
> >
> >
> >
> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Discussion-on-all-AJAX-requests-needing-context-tt5726132.html
> >
> > But what if other components on the page need to know their state, too,
> > before they can update their zoned contents?
> >
> > For example, a list of persons, L, in one part of the page might need to
> > refresh itself whenever a person is edited in component E somewhere else
> on
> > the page. That's easy (with a bit of bubbling up and perhaps some calls
> > down, or perhaps a bit of pub-sub), unless L is filtered, like this:
> >
> >
> >
> http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons
> >
> > E doesn't know about L or its filter, and nor should it, so the context
> on
> > the submit in E will not contain filter info.
> >
> > In that example I found an OK-ish solution but I'm looking for a better
> > way. The solution I found was to make L return javascript that submits
> the
> > filter form. I made use of the fact that the client knows its state. But
> > I'd prefer not to have that extra round-trip.
> >
> > So here's a crazy idea...
> >
> > What if, when the filter is submitted, we could do something like this:
> >
> > ajaxResponseRenderer.setQueryParameters("filter", filterValue);
> >
> > and Tapestry, client-side, would set that parameter on *every* Form,
> > EventLink, Select, etc. in the page. That way, no matter what event
> request
> > comes to the server, its request will be carrying the latest filter
> value.
> > In the example above, L would always be able to find out the current
> filter:
> >
> > String filterValue = request.getParameter("filter");
> >
> > Crazy, right?
> >
> > I suppose that each component that wants to use this facility would need
> a
> > way to tell Tapestry its initial values. Perhaps this could be
> declarative.
> >
> > Thoughts?
> >
> > Cheers,
> >
> > Geoff
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: dev-h...@tapestry.apache.org
> >
> >
>
Re: Discussion on AJAX requests need even more than a context?
If both L and E accepted a fields parameter (List) you could pass in the extra field ids to each. So you would pass L's filter clientId to E and pass E's filter clientId to L. When either L's filter or E's filter change, both filters are passed to the serverside event(s). The "group of fields" demo on tapestry-stitch shows an example of four fields rendered in a loop. When any of the four fields change all four values (and the loop context) are sent to the serverside event. It's similar to this use case except text fields instead of select. On 19 Mar 2014 22:43, "Geoff Callender" wrote: > Are you sure? How can @OnEvent solve the example I gave? > > Keep in mind that L and E are separate components. E is a reusable editor > that doesn't know about L. L is a reusable filter and list that doesn't > know about E, and which kindly provides a public method to allow others to > ask it to refresh itself. > > On 20/03/2014, at 12:42 AM, Lance Java wrote: > > > Hi Geoff, I'm thinking this can also be done with the onevent mixin I > > mentioned earlier. Since it can send a (configurable) list of clientside > > field values to the serverside event, you can send all field values that > > your event cares about. > > > > If two fields (eg select menus, text fields) determine the behaviour, > send > > both. > > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: Discussion on AJAX requests need even more than a context?
Hi Geoff, I'm thinking this can also be done with the onevent mixin I mentioned earlier. Since it can send a (configurable) list of clientside field values to the serverside event, you can send all field values that your event cares about. If two fields (eg select menus, text fields) determine the behaviour, send both.
Re: TAP5-2273: Where would TapestryIOCJUnit4ClassRunner live?
Hi Bob, I forgot to mention that I also feel that tapestry-test is a bit heavy weight. This junit runner is for testing tapestry-ioc apps. Tapestry-test has transitive dependencies on tapestry-web, selenium, jetty etc. I'm not sure people want all that on their classpath when testing an IOC only app. I'm beginning to think it belongs in it's own tapestry-ioc-test module.
TAP5-2273: Where would TapestryIOCJUnit4ClassRunner live?
I'd like to create a JUnit4ClassRunner to simplify integration testing of Tapestry IOC services. More details here https://issues.apache.org/jira/browse/TAP5-2273 I'm not sure which gradle module the test runner should live in? tapestry-test is deprecated and tapestry-internal-test is not intended for external use. Any suggestions?
Re: Discussion on all AJAX requests needing context
> Yes, I think it should be part of tapestry core. Unfortunately it clashes a bit with the "zone" parameter in "select". Does anybody support making a breaking change to remove the ajax behaviour from select if this mixin was added to core? > As a nod to jquery you could simply call it "on" :-) Yeah, I thought about that but didn't feel it was descriptive enough.
Re: Discussion on all AJAX requests needing context
It's probably worth mentioning my onevent mixin here. http://tapestry-stitch.uklance.cloudbees.net/oneventdemo Sorry to toot my own horn but I think it greatly simplifies many ajax interactions. It not only allows a context to be passed but it can also send a list of clientside field values in the ajax request. Currently you can only listen to one event per dom element. It would be nice to improve it to attach multiple listeners to multiple a single dom element. Does anyone else think this should be part of tapestry core? NB I think the "onevent" name is ambiguous. It could do with being renamed to "observe" or "listen".
Re: Loop and iterator
You can use two loops. Example here: http://tapestry-stitch.uklance.cloudbees.net/gallerydemo On 29 Jan 2014 16:12, "Dimitris Zenios" wrote: > Is it possible to make the loop component expose the iterator through a > public method? > > There are situations where a mixin might want to use it. > > Best Regards > Dimitris Zenios >
Re: VOTE: Tapestry 5.4-beta-1
+1 (non-binding) On 4 Dec 2013 23:01, "Howard Lewis Ship" wrote: > This is a vote, open to all committers, to create a beta release of > Tapestry 5.4. > > This represents the point at which new functionality should no longer be > added and, instead, the emphasis should be on bug fixing and documentation. > > Vote to run for three days. > > Howard M. Lewis Ship: +1 (binding) > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com >
Re: A couple of questions after playing around with T5.4 and the tapestry5-portlet bridge
I've never understood why you would want portlets in a tapestry app. Apart from maybe integrating with legacy code. What can a portlet give you that a tapestry component can not?
Re: Radio button event
You might be interested in one of these mixins. http://tapestry-stitch.uklance.cloudbees.net/oneventdemo http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/onevent
Re: [T5.4-a-22] Core stack being added to page non-HTML MarkupWriter-generated output
Hi Denis, my workaround was meant for Thiago since he's not using a template. You might find it difficult (near impossible) to invoke tapestry's template rendering yourself. I think you'll need to patch the issue, this will likely require tweaking the "JavaScriptSupport" MarkupRendererFilter that is contributed to the MarkupRenderer (in TapestryModule).
Re: [T5.4-a-22] Core stack being added to page non-HTML MarkupWriter-generated output
A workaround is to get a MarkupWriter instance from MarkupWriterFactory and return a StreamResponse.
Re: Proposal for a list of modules recommended by the Tapestry team
I prefer the idea of a registry where all tapestry add ons can get a mention with the ability to have the community rate and give feedback. Let the user decide whether the library is ok by croudsourcing feedback.
Re: Final call for TAP5-2070
You can have your cake and eat it! It's valid for a 404 response to have a body and a content type. On 31 Jul 2013 17:07, "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 >
Discussion: Future of tapestry-test & friends.
My 2p. I have had major headaches in the past maintaining selenium tests. The main problems are getting selenium to wait until the client is in a certain state. I found checking for AJAX responses or other custom conditions to be very flaky. Sometimes the only solution was to Thread.sleep() which I absolutely hate. Since geb is built on top of selenium, I can't see how it solves the problem but maybe there's some funky logic that alleviates the pain. I've ended up using selenium for simple sanity tests and never try to get too involved because the maintenance cost is not worth it. I must say that the spock testing in Tapestry originally put me off because I had to learn yet another language (ie groovy). I've since learned groovy and found it very simple to pick up. I think that groovy really excels in testing where you can very succinctly test code without the noise that java sometimes requires. So, Spock testing gets a big thumbs up from me but I can see how it might put some people off. Lance.
[VOTE] Lance Semmens as a committer
Thanks for your votes everyone. It's great to be part of the team.
Re: About GSoC 2013 Idea page
I think an interesting project would be to get Tapestry running on Netty instead of a servlet container. I know that the play framework can run on both and since 99% of tapestry is coded to it's own custom request, response and session interfaces it wouldn't be that hard. http://netty.io/ http://www.playframework.com/ -- View this message in context: http://tapestry.1045711.n5.nabble.com/About-GSoC-2013-Idea-page-tp5720315p5720382.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Submitting a value from a Form
By the way... the tapestry-dev list is for developers of tapestry. Messages such as this should be posted on the tapestry-users list. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Submitting-a-value-from-a-Form-tp5718882p5718887.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Submitting a value from a Form
Never use ${...} in attributes.
Use t:value="transactionQuote.pickupQuoteID" instead and tapestry will
create two way property binding which it can then get() and set().
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Submitting-a-value-from-a-Form-tp5718882p5718886.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Tapestry 5 developer rates
I'm in London... It seems that Spring MVC and JSF are the norm wherever I go (contractor / banking). I've never seen an advertised role mentioning Tapestry :( -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-5-developer-rates-tp5718832p5718839.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Getting current tapestry 5.4-SNAPSHOT head running in eclipse with git and gradle
There's also this: http://tapestry.apache.org/building-tapestry-from-source.html -- View this message in context: http://tapestry.1045711.n5.nabble.com/Getting-current-tapestry-5-4-SNAPSHOT-head-running-in-eclipse-with-git-and-gradle-tp5718810p5718812.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Getting current tapestry 5.4-SNAPSHOT head running in eclipse with git and gradle
Don't use "./gradlew eclipse" as gradle will not keep the eclipse project up-to-date with any changes. I haven't used the gradle tooling in eclipse but I'm assuming it's similar to the maven tooling. Instead of import "existing project into eclipse" there should be an option to import "existing gradle project" or similar. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Getting-current-tapestry-5-4-SNAPSHOT-head-running-in-eclipse-with-git-and-gradle-tp5718810p5718811.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: JS changes merged to master branch
> Some day, scrap the SeleniumTests and replace with Geb! I've found selenium testing to be flaky at best. I'm interested to hear your thoughts on what Geb will solve since it uses selenium's WebDriver under the hood. Does Geb have better mechanisms for waiting for the client to be in a particular state? With selenium, I sometimes find myself resorting to Thread.sleep() which I hate. -- View this message in context: http://tapestry.1045711.n5.nabble.com/JS-changes-merged-to-master-branch-tp5718747p5718772.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Infinite Scroll Pagination with Tapestry
I really like the infinite-scroll approach: http://www.infinite-scroll.com/ This library gracefully degrades when javascript is disabled so is also good for SEO[1]. You initially render links to all your pages and then the infinite-scroll script hides the page navigation and replaces it with scrolling. Taha has recently blogged about integrating tapestry with ScrollBeyond here: http://tawus.wordpress.com/2012/11/25/scrolling-pages-tapestry5-onscrollbeyond/ [1] http://en.wikipedia.org/wiki/Search_engine_optimization -- View this message in context: http://tapestry.1045711.n5.nabble.com/Infinite-Scroll-Pagination-with-Tapestry-tp5718284p5718285.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Javax mail in Tapestry
just having a laugh... no harshness intended ;) -- View this message in context: http://tapestry.1045711.n5.nabble.com/Javax-mail-in-Tapestry-tp5718005p5718011.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Javax mail in Tapestry
Firstly, you've asked this question on the tapestry-dev list when you should have posted it on tapestry-users. Secondly, you have asked two questions: 1. How do I handle a form in tapestry? 2. How do I send a mail using javax mail Answers: 1. http://tapestry.apache.org/forms-and-validation.html 2. http://en.wikipedia.org/wiki/RTFM -- View this message in context: http://tapestry.1045711.n5.nabble.com/Javax-mail-in-Tapestry-tp5718005p5718007.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Translator with Localized texts
1. Pass ComponentMessagesSource and ThreadLocale to the YesNoTranslator
constructor
2.
public String toClient(Boolean flag) {
Messages messages =
messagesSource.getApplicationCatalog(threadLocale.getLocale());
return (flag ? messages.get("boolean.true") :
messages.get("boolean.false");
}
3. Add entries for boolean.true and boolean.false for your languages to your
root application message catalogues
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Translator-with-Localized-texts-tp5717981p5717983.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: 5.4 JavaScript: Explicit vs. Unobtrusive initialization
Here's a first attempt at benchmarking the differences: http://jsfiddle.net/xPVy6/6/ -- View this message in context: http://tapestry.1045711.n5.nabble.com/5-4-JavaScript-Explicit-vs-Unobtrusive-initialization-tp5717787p5717818.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: 5.4 JavaScript: Explicit vs. Unobtrusive initialization
Sounds to me like a benchmark is needed to compare id lookup against full DOM scan for data attributes on all the major browsers on small, medium and large web pages. -- View this message in context: http://tapestry.1045711.n5.nabble.com/5-4-JavaScript-Explicit-vs-Unobtrusive-initialization-tp5717787p5717811.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Retrieveing specific desc from the base
In your pages / components @Inject private Locale locale; -- View this message in context: http://tapestry.1045711.n5.nabble.com/Retrieveing-specific-desc-from-the-base-tp5717585p5717589.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Retrieveing specific desc from the base
Tapestry supports localization for templates, messages and assets. It will firstly attempt to locate a resource for Romanian before falling back to the default unlocalized resource. http://tapestry.apache.org/assets.html http://tapestry.apache.org/localization.html If you'd like explicit control over which assets are being loaded you can @Inject AssetSource http://tapestry.apache.org/5.3.6/apidocs/org/apache/tapestry5/services/AssetSource.html -- View this message in context: http://tapestry.1045711.n5.nabble.com/Retrieveing-specific-desc-from-the-base-tp5717585p5717586.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: How to use jquery fullCalenar with Tapestry 5.3
The main requirements of fullcalendar is a feed of events (json) between a
start date and an end date [1]. Fullcalendar is very configurable but by
default, it will hit a URL of the form:
"/someURL?start=1262332800&end=1265011200"
1. Create an event on your page which uses a JSONObject to return a
TextStreamResponse.
public StreamResponse onGetEvents(@RequestParameter("start") long start,
@RequestParameter("end") long end)
2. Use componentResources.createEventLink("getEvents") to generate the base
URL
3. Pass the URL to the client (via JavaScriptSupport) to configure the
fullcalendar.
[1] http://arshaw.com/fullcalendar/docs/event_data/events_json_feed/
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/How-to-use-jquery-fullCalenar-with-Tapestry-5-3-tp5716186p5716190.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
Serverside push
Hi Tapestry team, As you may be aware, I've created a push implementation for tapestry [1] based on CometD [2]. I have seen recently that both wicket and primefaces are supporting push using atmosphere [3] which is far more portable than CometD. When I introduced tapestry-cometd, Howard mentioned that he was keen to include something similar in tapestry [4]. More recently he has said that he intends to include push support in tapestry by december [5]. So, before I go ahead and move from cometd to atmosphere, I'd like to know whether the tapestry team plan to use my implementation as a basis for the tapestry push functionality or if you plan to do a clean room implementation (in which case I won't bother). Cheers, Lance. [1] https://github.com/uklance/tapestry-cometd [2] http://cometd.org/ [3] https://github.com/Atmosphere/atmosphere [4] http://tapestry.1045711.n5.nabble.com/Announcement-Beta-release-of-tapestry-cometd-td5714020.html [5] https://speakerdeck.com/u/hlship/p/tapestry-5-dot-4-in-the-pipeline -- View this message in context: http://tapestry.1045711.n5.nabble.com/Serverside-push-tp5716189.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Overriding the header of a grid and sorting
Firstly, you have asked this question on the wrong list (it should be on the tapestry-user NOT tapestry-dev) Secondly, if you add a message with a key "propertyName-label", tapestry will use that instead of generating a user friendly name from the property name. @see TapestryInternalUtils.defaultLabel(String id, Messages messages, String propertyExpression) Cheers, Lance. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Overriding-the-header-of-a-grid-and-sorting-tp5715990p5716010.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Multiple Spring beans of same interface
I think that the spring integration needs a bit of an overhaul. I seem to remember that tapestry does not ignore "abstract" springs bean which can also cause problems. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Multiple-Spring-beans-of-same-interface-tp5714183p5714190.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Tapestry 5.1.0.5 to 5.2.6 migration. .html templates
Firstly, this question should be on the user's list (not the dev list). To change template lookup behaviour, you will need to either override or (more likely) decorate the ComponentResourceLocator. http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/pageload/ComponentResourceLocator.html http://tapestry.apache.org/tapestry-ioc-decorators.html -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-5-1-0-5-to-5-2-6-migration-html-templates-tp5713624p5713716.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: activation context in Tapestry
You will need to imlpement a ValueEncoder and contribute it to the ValueEncoderSource. http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/ValueEncoder.html http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ValueEncoderSource.html -- View this message in context: http://tapestry.1045711.n5.nabble.com/activation-context-in-Tapestry-tp5713555p5713557.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Git, my huge commit, etc.
Hi Howard, does this mean that all future test cases should be in groovy/spock? I think it's fair to say that everyone committing patches to Jira will have Java knowledge. Since a patch is more likely to be included if it has a test case, I think you are limiting your potential committers by requiring that test cases are written in spock/groovy. My 2p. Cheers, Lance. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Git-my-huge-commit-etc-tp5711062p5711296.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
