Re: [VOTE] 5.4.0

2015-12-24 Thread Geoff Callender 
Magnificent work.

> On 20 Dec 2015, at 12:59 am, Jochen Kemnade  wrote:
> 
> The vote passes, I'll release the artifacts and archives.
> 
> As my time is currently very limited, any help with the other steps,
> e.g. the Confluence and JIRA updates, is very welcome, see
> https://cwiki.apache.org/confluence/display/TAPESTRY/Release+Process for
> reference.
> 
> Binding votes:
> Thiago H. de Paula Figueiredo: +1
> Massimo Lusetti: +1
> Jochen Kemnade: +1
> 
> Non-binding votes:
> François Facon: +1
> Kalle Korhonen: +1
> Dimitris Zenios: +1
> Andreas Ernst: +1
> Chris Poulsen: +1
> Bob Harner: +1
> 
> Am 15.12.2015 um 17:17 schrieb Jochen Kemnade:
>> Hi,
>> 
>> I've created and uploaded a release of Tapestry 5.4.0, 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.0,
>> is ready.
>> 
>> I've also created a 5.4.0 tag in Git:
>> 
>> https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.4.0
>> 
>> 
>> 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
>> 
>> 
> 
> 


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

Re: JavaScriptSupport deprecations - Dynamic JavaScript generation?

2015-09-28 Thread Geoff Callender 
Try asking the question over in the users mailing list where others may have 
dealt with similar situations. It’s a discussion worth having.

Parameterising options to static JS wrapping Kendo components might be too 
onerous - I don’t know. The closest I’ve come to it is parameterising for 
HighCharts, which I balked at initially but later found it’s actually not too 
bad. I wrote a separate static JS script for each style of chart that I wanted 
to produce, and each one has slightly different options.

Here’s an example, just in case it helps. The static JS script in it produces a 
3D chart from 1 data series. The other scripts will have slightly different 
params.

void afterRender() {
JSONObject params = new JSONObject();

params.put("id", chartContainer.getClientId());
params.put("showLegend", false);

JSONArray categories = new JSONArray();
JSONArray series0 = new JSONArray();

for (int i = 0; i < 5; i++) {
if (i < evaluations.size()) {

categories.put(formatDefault(evaluations.get(i).getStartAt().toLocalDate()));

series0.put(deNullForJSONArray(toInteger(evaluations.get(i).getSomethingOrOther(;
}
else {
categories.put("");
series0.put(JSONObject.NULL);
}
}

params.put("categories", categories);
params.put("series0Values", series0);

params.put("yAxisTitle", 
messages.get(“something-or-other-axis-label"));

JSONArray yAxisLabels = new JSONArray();
yAxisLabels.put(toLabel(YesSlightNos.N));
yAxisLabels.put(toLabel(YesSlightNos.S));
yAxisLabels.put(toLabel(YesSlightNos.Y));
params.put("yAxisLabels", yAxisLabels);

params.put("yAxisFloor", 0);
params.put("yAxisCeiling", 2);
params.put("yAxisMinRange", 3);
params.put("yAxisTickInterval", 1);


javaScriptSupport.require("components/report/highcharts/ClassicOneSeries3DHighChart")
.invoke("init").with(params);
}

HTH,

Geoff

> On 29 Sep 2015, at 9:36 am, David Taylor  
> wrote:
> 
> Any additional thoughts regarding alternatives to the AddScript method for 
> JavaScriptSupport? Should I open a new bug report to capture this issue 
> and/or request removal of the AddScript deprecation?
> 
> -- 
> David Taylor
> http://www.extensiatech.com
> 
> 
> On 9/26/2015 10:49 PM, David Taylor wrote:
>> Geoff,
>> 
>> Thanks for the 5.3/5.4 comparison links. Seeing non-trivial working examples 
>> definitely clarified a few points for me regarding the new approach. The 
>> modal dialog example is also very interesting in its own right.
>> 
>> Looking at the examples, it seems the new module approach would require us 
>> to develop some form of client-side JavaScript API to create the necessary 
>> Kendo UI configuration objects. Parametrizing all of the possible Kendo 
>> configuration options to work within the constraints of a static JavaScript 
>> library would not be an easy task. The Kendo configuration is very flexible 
>> and varies by component. Perhaps it would be possible using a multi-step 
>> configuration approach, but I imagine that wouldn't be very pretty.
>> 
>> Currently we generate the JavaScript code server side and emit it into the 
>> page using the deprecated addScript() method. This allows us to construct 
>> the Kendo JavaScript configuration taking into account the configuration of 
>> the associated Tapestry-Kendo wrapper components and data source information 
>> from our middle tier. The details of the JavaScript code being generated are 
>> rather dynamic so it does not lend itself to a static configuration approach.
>> 
>> Barring any additional approaches, it seems the addScript() method is 
>> currently the most workable option. Does anyone know why this method was 
>> marked as deprecated? Any chance it could be removed from the deprecation 
>> list?
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>

Re: JavaScriptSupport deprecations - Dynamic JavaScript generation?

2015-09-26 Thread Geoff Callender 
This may help. Compare these:

T5.3: 
http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/javascript 

T5.4: 
http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/javascript
 


T5.3: 
http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/robust 

T5.4: 
http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/robust 


T5.4: 
http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/modal/1 


Geoff

> On 27 Sep 2015, at 8:17 am, David Taylor  
> wrote:
> 
> Hello,
> 
> We are working on several Tapestry 5.4 applications that make extensive use 
> of Kendo UI components in addition to the standard Tapestry components. We 
> have created Tapestry components wrapping the Kendo UI components, but see 
> that the JavaScriptSupport methods we are using in setupRender() to emit our 
> JavaScript have been marked as deprecated. The remaining non-deprecated 
> JavaScriptSupport methods do not appear to provide the functionality needed 
> to dynamically assemble the required Kendo UI Javascript initialization logic 
> (e.g. http://docs.telerik.com/kendo-ui/framework/datasource/overview).
> 
> What mechanisms exist in Tapestry 5.4 that can be used to replace the 
> functionality of the deprecated addInitializerCall() and addScript() methods? 
> The remaining methods in JavaScriptSupport seem to be focused on the use of 
> static JavaScript files which does not work well for heavily 
> JavaScript-driven component sets such as Kendo UI or jQuery UI.
> 
> While the approach we are currently using works well, it is clearly not 
> supportable long term given the Tapestry method deprecations. Any feedback on 
> how this logic should be structured in Tapestry 5.4 would be greatly 
> appreciated.
> 
> -- 
> David Taylor
> http://www.extensiatech.com
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>

Re: [VOTE] 5.4-beta-35

2015-08-24 Thread Geoff Callender 
Jochen, your tireless efforts are astonishing and invaluable, and I just want 
to say thank you.

BTW, I’ve upgraded the JumpStart preview to use beta-35 and beta-35 is looking 
good.

http://jumpstart.doublenegative.com.au/jumpstart7/

Geoff

 On 24 Aug 2015, at 4:54 pm, Jochen Kemnade jochen.kemn...@eddyson.de wrote:
 
 I've also updated the Download page, but it seems to take a while for the 
 changes to populate.
 This is my first public release, so I hope this is all I need to do.
 
 Am 23.08.2015 um 14:49 schrieb Jochen Kemnade:
 The vote passes, I'll release the artifacts.
 
 Binding votes:
 Thiago H. de Paula Figueiredo: +1
 Howard M. Lewis Ship: +1
 Massimo Lusetti: +1
 Jochen Kemnade: +1
 
 Non-binding votes:
 Andreas Ernst: +1
 Dimitris Zenios: +1
 François Facon: +1
 Bob Harner: +1
 Kalle Korhonen: +1
 Lance S: +1
 
 
 Am 18.08.2015 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
 
 
 
 
 
 -
 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: [SUCCESS] Switch to release candidate

2015-08-04 Thread Geoff Callender 
Is it time to revisit the question of dropping Java 6 support in T5.4? There’s 
a reason they dropped Java 6 support: Java 6 was EOL’d two-and-a-half-years ago 
(Feb 2013)! Well, technically, they ended public updates. Even Java 7 has ended 
since then (public updates ended in April 2015)! So why must we keep Java 6 
support?

 On 4 Aug 2015, at 6:03 pm, Jochen Kemnade jochen.kemn...@eddyson.de wrote:
 
 Am 04.08.2015 um 05:29 schrieb Kalle Korhonen:
 There's a few tests failing, at least for me,
 
 Which one?
 
 and I see Jochen trying to improve things.
 
 Well, I've given up, I think they are running Firefox 39 on hemera and we'd 
 need a new Selenium version, but we can't upgrade to 2.47+ because they 
 dropped support for Java 6. I guess we won't be able to run the UI tests for 
 5.4 anymore, which is a shame.
 Of course, we could use a dedicated build machine, but someone would need to 
 provide one. I tried to run the build on my Pi, but that's much too slow.
 
 Jochen
 
 -
 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: Jenkins builds failing again

2015-07-23 Thread Geoff Callender 
You must feel incredibly frustrated. This is a ridiculous state of affairs.


 On 23 Jul 2015, at 12:08 am, Jochen Kemnade jochen.kemn...@eddyson.de wrote:
 
 Am 22.07.2015 um 15:56 schrieb Taha Siddiqi:
 I am sure you would have tried this but just in case  you missed. Did you 
 check your Firefox version is compatible with the selenium version we are 
 using.
 
 I don't know which Firefox version is running on hemera (ubuntu3) and I'm not 
 allowed to SSH there.
 
 -
 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] Switch to release candidate

2015-07-14 Thread Geoff Callender 
Given there’s no response, can we at least get out a new public beta? 

To my mind there has not been a usable public beta since beta-6, which was a 
long time ago, so the need for this is huge.

Geoff

 On 15 Jul 2015, at 1:05 am, Thiago H de Paula Figueiredo thiag...@gmail.com 
 wrote:
 
 On Tue, 14 Jul 2015 11:47:28 -0300, Jochen Kemnade 
 jochen.kemn...@eddyson.de wrote:
 
 Hi,
 
 Hi!
 
 
 Am 14.07.2015 um 15:26 schrieb Thiago H de Paula Figueiredo:
 Couldn't that be left for 5.4.0 final so we can get the release
 candidate out?
 
 I may have an old-fashioned view of things, but for me, a release candidate 
 is something that we think is ready to be released as the final version. If 
 we know that there are issues left that we want to fix before 5.4.0, for me, 
 that's exactly what makes current releases *not* release candidates.
 
 I cannot argue with that, Jochen. :)
 
 Is anyone planning to work on that ticket?
 
 -- 
 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: Confluence macro contentbylabel failing

2015-07-09 Thread Geoff Callender 
Bob Harner’s thoughts in https://issues.apache.org/jira/browse/TAP5-2485 
https://issues.apache.org/jira/browse/TAP5-2485 might hold a clue.

 On 10 Jul 2015, at 9:46 am, Kalle Korhonen kalle.o.korho...@gmail.com wrote:
 
 Several users have left comments in the documentation that they don't see
 the examples. At least one of the issues is that the contentbylabel macro
 is giving an undescriptive error BadRequestException: Could not parse cql
 : null (see e.g.
 https://cwiki.apache.org/confluence/display/TAPESTRY/Overriding+Exception+Reporting).
 I don't know if there's been a Confluence upgrade or what else could have
 cause it. Does anybody know anything more?
 
 Kalle

Re: [FAILED] Switch to release candidate

2015-06-30 Thread Geoff Callender 
That’s good news.

 On 29 Jun 2015, at 10:59 pm, Thiago H de Paula Figueiredo 
 thiag...@gmail.com wrote:
 
 On Sun, 28 Jun 2015 20:57:10 -0300, Geoff Callender 
 geoff.callender.jumpst...@gmail.com 
 mailto:geoff.callender.jumpst...@gmail.com wrote:
 
 When will this be resurrected? I, for one, am busting to see a quality RC. 
 Our production sites have been stuck in beta-6 for a long time!
 
 By the way, this weekend I could finally fix 
 https://issues.apache.org/jira/browse/TAP5-2029 
 https://issues.apache.org/jira/browse/TAP5-2029, so, for me, there aren't 
 any blockers for a candidate release or even a final release of 5.4.0.
 
 
 Geoff
 
 On 8 Jun 2015, at 7:19 pm, Massimo Lusetti mluse...@gmail.com wrote:
 
 I've been snorkeling in the sea so miss the vote... but I'm more then
 happy to cast my binding vote.
 
 Massimo Lusetti: +1 (binding)
 
 On Fri, Jun 5, 2015 at 7:31 PM, Howard Lewis Ship hls...@gmail.com wrote:
 Sorry about that ... yes, we have two +1 but not three.
 
 On Fri, Jun 5, 2015 at 8:35 AM, Thiago H de Paula Figueiredo 
 thiag...@gmail.com wrote:
 
 On Fri, 05 Jun 2015 11:42:09 -0300, Howard Lewis Ship hls...@gmail.com
 wrote:
 
 Well, the vote failed; only one binding +1 (mine).
 
 
 I've voted +1 (binding) and mentioned the two issues I think block a final
 release. Didn't my message arrive to you guys? Here's a copy of it:
 
 I have two service proxy annotations bugs on me, both on
 https://issues.apache.org/jira/browse/TAP5-2029: T-IoC blows up if service
 interface method and service implementation method have the same
 annotation, which is the harder issue, and a problem with generics I've
 partially fixed which doesn't blow up, just doesn't copy an annotation. I
 think the first one is a showstopper for 5.4.0 final, but not for a
 candidate release. I'll try to fix them this week.
 
 Thiago H. de Paula Figueiredo: +1 (binding)
 
 
 Any ideas on when we'll be ready to get an RC out?  What are the real
 blockers?
 
 
 
 On Fri, Jun 5, 2015 at 3:32 AM, Lance Java lance.j...@googlemail.com
 wrote:
 
 Lance S
 +1 (non-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
 
 
 
 
 --
 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
 
 
 
 --
 Massimo Lusetti
 
 -
 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 
 mailto:dev-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: dev-h...@tapestry.apache.org 
 mailto:dev-h...@tapestry.apache.org
 
 
 
 -- 
 Thiago H. de Paula Figueiredo
 Tapestry, Java and Hibernate consultant and developer
 http://machina.com.br http://machina.com.br/

Re: [FAILED] Switch to release candidate

2015-06-28 Thread Geoff Callender 
When will this be resurrected? I, for one, am busting to see a quality RC. Our 
production sites have been stuck in beta-6 for a long time!

Geoff

 On 8 Jun 2015, at 7:19 pm, Massimo Lusetti mluse...@gmail.com wrote:
 
 I've been snorkeling in the sea so miss the vote... but I'm more then
 happy to cast my binding vote.
 
 Massimo Lusetti: +1 (binding)
 
 On Fri, Jun 5, 2015 at 7:31 PM, Howard Lewis Ship hls...@gmail.com wrote:
 Sorry about that ... yes, we have two +1 but not three.
 
 On Fri, Jun 5, 2015 at 8:35 AM, Thiago H de Paula Figueiredo 
 thiag...@gmail.com wrote:
 
 On Fri, 05 Jun 2015 11:42:09 -0300, Howard Lewis Ship hls...@gmail.com
 wrote:
 
 Well, the vote failed; only one binding +1 (mine).
 
 
 I've voted +1 (binding) and mentioned the two issues I think block a final
 release. Didn't my message arrive to you guys? Here's a copy of it:
 
 I have two service proxy annotations bugs on me, both on
 https://issues.apache.org/jira/browse/TAP5-2029: T-IoC blows up if service
 interface method and service implementation method have the same
 annotation, which is the harder issue, and a problem with generics I've
 partially fixed which doesn't blow up, just doesn't copy an annotation. I
 think the first one is a showstopper for 5.4.0 final, but not for a
 candidate release. I'll try to fix them this week.
 
 Thiago H. de Paula Figueiredo: +1 (binding)
 
 
 Any ideas on when we'll be ready to get an RC out?  What are the real
 blockers?
 
 
 
 On Fri, Jun 5, 2015 at 3:32 AM, Lance Java lance.j...@googlemail.com
 wrote:
 
 Lance S
 +1 (non-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
 
 
 
 
 --
 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
 
 
 
 -- 
 Massimo Lusetti
 
 -
 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 for 5.4-beta-25 tomorrow

2014-12-31 Thread Geoff Callender 
That's music to my ears. Good luck. And Happy New Year!

On 1 Jan 2015, at 6:44 am, Howard Lewis Ship hls...@gmail.com wrote:

 I'm still struggling with a solution to that.  I may devote some time later
 today.
 
 On Tue, Dec 30, 2014 at 6:26 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 Sorry but I will be voting against because of this serious regression,
 where server-side form field error messages no longer behave the same in
 AJAX requests as non-AJAX requests:
 
https://issues.apache.org/jira/browse/TAP5-2391
 
 It crept in after beta-6, before beta-22.
 
 Geoff
 
 On 31 Dec 2014, at 12:35 pm, Howard Lewis Ship hls...@gmail.com wrote:
 
 Have to run right now, but I'll send out a vote tomorrow.
 
 Hopefully, rc-1 can follow in a week or two.
 
 --
 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
 
 
 
 
 -- 
 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: Vote for 5.4-beta-25 tomorrow

2014-12-30 Thread Geoff Callender 
Sorry but I will be voting against because of this serious regression, where 
server-side form field error messages no longer behave the same in AJAX 
requests as non-AJAX requests:

https://issues.apache.org/jira/browse/TAP5-2391

It crept in after beta-6, before beta-22.

Geoff

On 31 Dec 2014, at 12:35 pm, Howard Lewis Ship hls...@gmail.com wrote:

 Have to run right now, but I'll send out a vote tomorrow.
 
 Hopefully, rc-1 can follow in a week or two.
 
 -- 
 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: Documentation

2014-10-25 Thread Geoff Callender 
On 25 Oct 2014, at 10:15 am, Howard Lewis Ship hls...@gmail.com wrote:

 I've spent a couple of hours hitting some top bugs and working on some
 improvements to the documentation.
 
 I can't say how much I hate confluence.

Really?

 I've been using an alternate tool, Dexy, of late. It's python and quirky,
 but gets the job done.
 
 I'd love to have the documentation be part of the project; that could
 easily be the end of all the since/until/deprecated nonsense.

I find it really helpful having the since/until/deprecated stuff right there in 
one place. Usually there is an explanation of the rationale for the change, and 
that's priceless. It's a learning tool. Furthermore, it helps when preparing to 
upgrade and deciding how to approach it; it's instructive to anyone coming from 
an earlier version; and it gives insight to anyone who is looking at code that 
has evolved from an earlier version but is unfamiliar with older versions.

 -- 
 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: [SUCCESS] Apache Tapestry 5.4-beta-22

2014-09-25 Thread Geoff Callender 
The Downloads page still says beta-6 is the latest, so I presume the javadoc 
and other doco is still beta-6.
Has it been announced on the users mailing list?
Are there release notes?

Just asking so I can make plans.

Cheers,

Geoff

On 25 Sep 2014, at 5:00 pm, Massimo Lusetti mluse...@gmail.com wrote:

 That's great!
 
 On Thu, Sep 25, 2014 at 6:57 AM, Kalle Korhonen kalle.o.korho...@gmail.com
 wrote:
 
 On Wed, Sep 24, 2014 at 5:55 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 When will beta-22 go public?
 
 
 What do you mean?
 
 http://repo1.maven.org/maven2/org/apache/tapestry/tapestry-core/5.4-beta-22/
 
 Kalle
 
 
 
 
 On 16 Sep 2014, at 8:00 am, Howard Lewis Ship hls...@gmail.com wrote:
 
 
 
 I've created and uploaded a release of Tapestry 5.4-beta-22, ready to
 be
 voted upon.
 A few more fixes, including ones that resulted in aborted prior votes,
 have been resolved.
 
 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-22,
 is ready.
 
 I've also created a 5.4-beta-22 tag in Git:
 
 
 
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=4bc52d876ba64d5843bb9661187a9fdabffe2b33
 
 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.
 
 Binding votes:
 
 Howard M. Lewis Ship: +1
 Thiago H. de Paula Figueiredo: +1
 
 Non-binding votes:
 
 Jochen Kemnade: +0
 Kalle Korhonen: +1
 Bob Harner: +1
 Taha Hafeez: +1
 François Facon: +1
 Lance S. +1
 
 
 
 
 
 --
 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
 
 
 
 
 
 
 -- 
 Massimo Lusetti


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

Re: [SUCCESS] Apache Tapestry 5.4-beta-22

2014-09-25 Thread Geoff Callender 
Thanks. A small thing: the Download page says emphatically the most recent is 
5.4-beta-6 then provides only beta-22 download. Cognitive dissonance.


On 26 Sep 2014, at 9:41 am, Howard Lewis Ship hls...@gmail.com wrote:

 Better late than never, I've been updating the web site.
 
 On Thu, Sep 25, 2014 at 3:05 AM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 The Downloads page still says beta-6 is the latest, so I presume the
 javadoc and other doco is still beta-6.
 Has it been announced on the users mailing list?
 Are there release notes?
 
 Just asking so I can make plans.
 
 Cheers,
 
 Geoff
 
 On 25 Sep 2014, at 5:00 pm, Massimo Lusetti mluse...@gmail.com wrote:
 
 That's great!
 
 On Thu, Sep 25, 2014 at 6:57 AM, Kalle Korhonen 
 kalle.o.korho...@gmail.com
 wrote:
 
 On Wed, Sep 24, 2014 at 5:55 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 When will beta-22 go public?
 
 
 What do you mean?
 
 
 http://repo1.maven.org/maven2/org/apache/tapestry/tapestry-core/5.4-beta-22/
 
 Kalle
 
 
 
 
 On 16 Sep 2014, at 8:00 am, Howard Lewis Ship hls...@gmail.com
 wrote:
 
 
 
 I've created and uploaded a release of Tapestry 5.4-beta-22, ready to
 be
 voted upon.
 A few more fixes, including ones that resulted in aborted prior
 votes,
 have been resolved.
 
 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-22,
 is ready.
 
 I've also created a 5.4-beta-22 tag in Git:
 
 
 
 
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=4bc52d876ba64d5843bb9661187a9fdabffe2b33
 
 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.
 
 Binding votes:
 
 Howard M. Lewis Ship: +1
 Thiago H. de Paula Figueiredo: +1
 
 Non-binding votes:
 
 Jochen Kemnade: +0
 Kalle Korhonen: +1
 Bob Harner: +1
 Taha Hafeez: +1
 François Facon: +1
 Lance S. +1
 
 
 
 
 
 --
 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
 
 
 
 
 
 
 --
 Massimo Lusetti
 
 
 -
 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


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

Re: [SUCCESS] Apache Tapestry 5.4-beta-22

2014-09-24 Thread Geoff Callender 
When will beta-22 go public?


On 16 Sep 2014, at 8:00 am, Howard Lewis Ship hls...@gmail.com wrote:

 
 
 I've created and uploaded a release of Tapestry 5.4-beta-22, ready to be
 voted upon.
 A few more fixes, including ones that resulted in aborted prior votes,
 have been resolved.
 
 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-22,
 is ready.
 
 I've also created a 5.4-beta-22 tag in Git:
 
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=4bc52d876ba64d5843bb9661187a9fdabffe2b33
 
 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.
 
 Binding votes:
 
 Howard M. Lewis Ship: +1
 Thiago H. de Paula Figueiredo: +1
 
 Non-binding votes:
 
 Jochen Kemnade: +0
 Kalle Korhonen: +1
 Bob Harner: +1
 Taha Hafeez: +1
 François Facon: +1
 Lance S. +1
 
 
 
 
 
 --
 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: [5.4-beta-6] How to update a Zone inside a loop ?

2014-08-10 Thread Geoff Callender 
This is a pretty unsatisfactory solution. Why don't the T5.4 JIRA issues simply 
show which beta they've been released into?

On 10 Aug 2014, at 6:58 pm, Basile Chandesris ba...@free.fr wrote:

 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.gita=searchh=HEADst=commits=TAP5-2329
  - 2014-05-27
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.gita=searchh=HEADst=commits=zone+
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=0119f9a890c8becb80fa1d5f36c1ab1f4ec8660c
 Thu, 7 Aug 2014 - 5.4-beta-16 is available
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=90766995f59048cb7f7d4cf042a21a9d728583db
 Sun, 20 Jul 2014 - 5.4-beta-15 is available
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=ded30cceeca17469c7081255756599703bd6cd40
 Thu, 17 Jul 2014 - 5.4-beta-14 is available
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=57171a34a8fcbaf8fe25749096a00b262ab4c871
 Mon, 23 Jun 2014 - 5.4-beta-13 is available
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=6ee341ae2578d0a455a6deccb392a0f352c6f624
 Fri, 20 Jun 2014 - 5.4-beta-12 is available
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=4780b04b5c2bdebbd3f4f96691e3f15727b5cb09
  
 Tue, 17 Jun 2014 - 5.4-beta-11 is available
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=326786c8b739e8b093794710d20a7a28631813da
 Tue, 3 Jun 2014 - 5.4-beta-10 is available
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=d49ddd604f4387b8d0c0f42ccee75191967a6fa1
 Tue, 3 Jun 2014 - 5.4-beta-9 is available
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=2650b107c194a06cfc855b1526d8fa06012ec2c0
 Mon, 2 Jun 2014 - 5.4-beta-8 is available
 
 http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/template/NamlServlet.jtp?macro=search_pagenode=2375124query=votesort=date
 
 http://www.apache.org/dev/release.html
 
 
 Le 09/08/14 23:14, Muhammad Gelbana a écrit :
 But even if I can submit a context value, how can I know the which zone to
 update ? (i.e. what is zone's id ?)​
 
 I mentioned that zones and select components are repeated in a loop.
 
 *-*
 *Muhammad Gelbana*
 http://www.linkedin.com/in/mgelbana
 
 
 On Sat, Aug 9, 2014 at 4:59 PM, Muhammad Gelbana m.gelb...@gmail.com
 wrote:
 
 I can't figure out the version having this fix !
 
 I can only see that 5.4-beta-6 was announced on tapestry.apache.org few
 days before Thiago committed the fox on GIT but I cannot figure out the
 exact version having this fix and I don't know how the developers organize
 their brnaches
 
 *-*
 *Muhammad Gelbana*
 http://www.linkedin.com/in/mgelbana
 
 
 On Sat, Aug 9, 2014 at 4:11 PM, Lance Java lance.j...@googlemail.com
 wrote:
 
 Here's the jira
 
 https://issues.apache.org/jira/plugins/servlet/mobile#issue/TAP5-2301
 
 Looks like you're in luck... Thiago has implemented it!
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 


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

Is the Users Mailing List broken again?

2014-06-29 Thread Geoff Callender 
It's been almost 3 days since any mail arrived in the Users mailing List. Is it 
broken again?
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org

Where's the 5.4 javadoc?

2014-06-08 Thread Geoff Callender 
Am I looking in the wrong place for T5.4 javadoc? The doco I'm looking at shows 
Autocomplete without a context parameter:


http://people.apache.org/~hlship/t5api/apidocs/org/apache/tapestry5/corelib/mixins/Autocomplete.html

but I think that's out of date, judging by this issue:

https://issues.apache.org/jira/browse/TAP5-1783

Also, is there a reason that fixed issues in JIRA don't show which beta they're 
first released into?

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?

2014-03-26 Thread Geoff Callender 
Maybe L (which contains F) just needs to use:

@Persist(cookie) 
private String filterValue

Downsides might be it's not bookmarkable, and the client-side state persists 
beyond the page.

On 26/03/2014, at 11:47 AM, 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: Discussion on AJAX requests need even more than a context?

2014-03-25 Thread Geoff Callender 
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 all AJAX requests needing context

2014-03-25 Thread Geoff Callender 
Agreed, but I think Tapestry can go a big step towards to handling more AJAX 
cases without that. Howard, could you comment on this other discussion:


http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Discussion-on-AJAX-requests-need-even-more-than-a-context-tt5726230.html

On 26/03/2014, at 5:03 AM, Howard Lewis Ship wrote:

 I would definitely agree that Tapestry has a problem dealing with complex
 Ajax pages.  Essentially, for Tapestry to do the right thing, it has to
 have a model of what's going on in the client browser and no such model
 exists.
 
 Passing a page context and an individual event context helps, but you start
 getting into scenarios where there's a context for the Zone and a context
 for the link/form inside the Zone.
 
 Past a certain point, it simply feels like we're trying to plug the holes
 in the leaky dike.
 
 I think the correct way forwards is to say that Tapestry's built-in Ajax
 support is great for simple to low-moderate complexity ... but if you are
 doing something very dynamic, it is not the best approach. Moving complex
 UI logic to the client is the right approach, and the challenge is to
 figure out how to move Tapestry and it's community in that direction.
 
 
 On Thu, Mar 13, 2014 at 7:32 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 To all Tapestry devs,
 
 Please, I want your thoughts before I file a JIRA, just in case I have my
 wires crossed.
 
 I'm thinking that Tapestry has real problems working with complex AJAX
 pages because there are AJAX components that don't have a context
 parameter.
 
 The problem I see is that a deeply nested component, C, cannot handle an
 event from an AJAX sub-component unless C can reconstruct its context, ie.
 C has to be able to restore its parameters. This has been solved in Form
 and EventLink by giving them a context parameter. eg.
 
onPrepareForSubmit(Integer contextArg1) { etc. }
 
onMyevent(Integer contextArg1) { etc. }
 
 I routinely use this context to restore C's parameters, eg.
 
@Parameter
private Integer parameter1;
 
onPrepareForSubmit(Integer parameter1) {
this.parameter1 = parameter1;
}
 
 But what about Select and Grid? Neither of them has a context.
 
 Without a context, C can't handle 2 or more AJAX Select components. When
 one sends an event, C has no idea of the value of the other, nor of its own
 parameters. A context would fix all of this.
 
 Without a context, an inplace request from a GridPager can't remind C was
 currently selected or how the Grid was being filtered. The same goes for
 Grid column select events. (See
 https://issues.apache.org/jira/browse/TAP5-2297)
 
 There are workarounds, but with a context I think we wouldn't need them:
 
 1. Use @Persist. Well, we all try to avoid this.
 
 2. Include C's parameters in the page's context and make sure they're
 passed down through every nested component down to C. But surely that's not
 reasonable. What if the page is concerned with a Hospital, but in it our
 components drill down through a Ward to a Patient and C is concerned with
 the Patient's Diagnosis. Does it really make sense to pass diagnosisId in
 through the page context and down through all the in-between components?
 Following this logic, we could end up with every parameter of every
 component in the page context.
 
 3. Use activation request parameters, but it appears to me to be messy.
 @ActivationRequestParameters is only available at the page level, so again
 we have to pass them all the way down. Even if we do this, it's a nuisance
 to pass them all the way UP in the first place. And again we could end up
 with every parameter of every component being declared in the page.
 
 4. Perhaps C can get and set request parameters by hand, but why? Isn't a
 context better?
 
 Am I seeing an issue that doesn't exist? Is there a better way?
 
 Cheers,
 
 Geoff
 
 
 
 
 -- 
 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: Discussion on AJAX requests need even more than a context?

2014-03-20 Thread Geoff Callender 
Doesn't that mean that E is no longer independent, because it has to know how 
many clientIds will arrive in each request? 

One thing I like about what I'm proposing is the way it scopes the request 
parameters to the component that needs them, ie. other components don't know 
anything about them. If there's a name clash then perhaps Tapestry could warn 
us in dev, or perhaps it could handle it transparently.

Can @OnEvent be used with a Submit/POST like E uses?

On 20/03/2014, at 8:15 PM, Lance Java wrote:

 If both L and E accepted a fields parameter (ListString) 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 geoff.callender.jumpst...@gmail.com
 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
 
 


-
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?

2014-03-20 Thread Geoff Callender 
Hi Dmitry,

Every URL on the client-side could be updated. What we're talking about is 
setting a query parameter in every URL, eg. putting filter=filterValue in every 
URL, whether it needs it or not. It's harmless! That's the beauty of named 
parameters.

In my example, if no AJAX was involved then the page render would tack 
filter=filterValue onto every URL. If AJAX is involved, then following a 
submit of a new list filter, the response would be AJAX and something on the 
client-side would find every URL and make sure it includes filter=filterValue. 
As a result, the client-side page would end up exactly the same as if we'd done 
a full page render.

Regarding your scenario where E is added to the DOM after the latest change in 
F, maybe the answer is for Tapestry on the client-side to keep a cache of the 
activation request parameters and apply them to new URLs it finds in all 
responses, ie. it would add/update query parameters in those URLs.


On 20/03/2014, at 9:15 PM, Dmitry Gusev wrote:

 Hi Geoff,
 
 How would you know on the client-side which URLs you have to update? What
 if some form or a link in client-side DOM isn't a tapestry URL and
 shouldn't be updated?
 Or what if I generated some event URLs on the server-side and passed them
 via JS initializer specification to client-side and they're located in
 JavaScript objects or stored as data-* attributes in DOM -- how would these
 URLs be updated?
 
 As for your example, it's not clear to me. You said you have filter F, list
 L, and editor E. Imagine that only list and filter are on screen and all
 event links updated on filter submit as you suggested. Then you're clicking
 on some link (from the list?) to display the editor E. New editor will be
 rendered on the server side and will appear in client-side via zone update.
 Note that though you will have the filter request parameter on the server
 side during E rendering - you can't do anything with it, because you said
 that E is generic and doesn't know about filters. Later if you click submit
 on editor, it's submit link won't contain filter information on
 client-side, because you invoked
 ajaxResponseRenderer.setQueryParameters(filter,
 filterValue); before editor E appeared in the client-side DOM and it's
 submit link haven't been updated. Am I missing something?
 
 
 
 On Wed, Mar 19, 2014 at 4:45 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 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
 
 
 
 
 -- 
 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: Discussion on AJAX requests need even more than a context?

2014-03-20 Thread Geoff Callender 
Hi Nourredine,

I like Dmitry's pub-sub, especially for non-AJAX communication between 
components in a page. 

However, I don't think it can address my example problem in the AJAX world. 
That problem is this: if E is independent of L (it is), then E won't publish 
what L needs (ie. L's filter value).

Geoff


On 20/03/2014, at 8:21 PM, 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
 
 


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

Discussion on AJAX requests need even more than a context?

2014-03-19 Thread Geoff Callender 
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?

2014-03-19 Thread Geoff Callender 
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?

2014-03-19 Thread Geoff Callender 
No, there's no need for complete page state in any request. In the example I 
gave, we restored the necessary state with just one query parameter: filter. 
Component contexts looked after the rest.

Think of it as bringing @ActivationRequestParameter down from the page level to 
the component/zone level, just for AJAX.

When there's no AJAX, @ActivationRequestParameter works fine: during page 
render every requester in the page (Form, EventLink, etc) gets the activation 
request parameters baked into its URLs. Every request that comes in sets the 
@ActivationRequestParameter.

But when there is AJAX, each server-side component needs a way to return its 
activation request parameters and have the client-side update every URL in the 
page, not just the URLs in the returned zone(s). That's all I'm proposing.

On 20/03/2014, at 12:59 AM, Chris Poulsen wrote:

 Hi,
 
 The over all idea is really interesting and nice, but I think it is a hard
 one to implement correctly in the framework.
 
 Having complete page state in GET requests (as context/parameters) may be
 troublesome for complex pages with a lot of state (there seem to be an URL
 size limit around 2000 chars).
 
 Using POST may be an option for some things or a totally different paradigm
 where state is kept server side and the key to locate the state is passed
 around could be possible... Even though the existing solutions with the
 server side state clearly has their own set of issues.
 
 The discussion is very interesting though ;)
 
 -- 
 Chris


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

Re: Discussion on all AJAX requests needing context

2014-03-15 Thread Geoff Callender 
Nice one, Thiago.  https://issues.apache.org/jira/browse/TAP5-2301.


On 15/03/2014, at 4:51 AM, Thiago H de Paula Figueiredo wrote:

 On Thu, 13 Mar 2014 23:32:55 -0300, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 To all Tapestry devs,
 
 Hi!
 
 I agree with you. That's one of the first things I want to do when I go back 
 to work on the Month of Tapestry. Please file a JIRA. And thanks for bringing 
 that up. ;)
 
 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: Discussion on all AJAX requests needing context

2014-03-15 Thread Geoff Callender 
Chris,

In case you haven't seen it, I explored some of the issues of Grid, filtering, 
and AJAX here: 


http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons

Don't know if there are any useful ideas in there for you.

Geoff

On 14/03/2014, at 8:15 PM, Chris Poulsen wrote:

 Hi,
 
 This is a well timed discussion ;-)
 
 I've been spending some time creating a grid version that supports
 filtering and not uses @Persist internally. I have been forced to create a
 new Select to get context support, I've decided not to create context
 support for the grid until it is actually needed.
 
 I do not see Select as a scaffolding component in the same category as
 grid, Select has a pretty narrow scope while it is most likely impossible
 to make a grid that provides everything that everyone need.
 
 If it is the thought that everyone should override the Select component to
 get context support, it would be nice if it was more trivial to
 extend/modify the core/Select.
 
 -- 
 Chris
 
 
 On Fri, Mar 14, 2014 at 9:53 AM, Dusko Jovanovski dusk...@gmail.com wrote:
 
 You are absolutely right. Context for Select and Grid would be a welcome
 addition. Even though these are only scaffolding components that are meant
 to be extended and modified to fit your use cases, most people use them as
 they are. There may be some other components that need this addition, but
 none come to mind at the moment.
 
 
 On Fri, Mar 14, 2014 at 3:32 AM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 To all Tapestry devs,
 
 Please, I want your thoughts before I file a JIRA, just in case I have my
 wires crossed.
 
 I'm thinking that Tapestry has real problems working with complex AJAX
 pages because there are AJAX components that don't have a context
 parameter.
 
 The problem I see is that a deeply nested component, C, cannot handle an
 event from an AJAX sub-component unless C can reconstruct its context,
 ie.
 C has to be able to restore its parameters. This has been solved in Form
 and EventLink by giving them a context parameter. eg.
 
onPrepareForSubmit(Integer contextArg1) { etc. }
 
onMyevent(Integer contextArg1) { etc. }
 
 I routinely use this context to restore C's parameters, eg.
 
@Parameter
private Integer parameter1;
 
onPrepareForSubmit(Integer parameter1) {
this.parameter1 = parameter1;
}
 
 But what about Select and Grid? Neither of them has a context.
 
 Without a context, C can't handle 2 or more AJAX Select components. When
 one sends an event, C has no idea of the value of the other, nor of its
 own
 parameters. A context would fix all of this.
 
 Without a context, an inplace request from a GridPager can't remind C was
 currently selected or how the Grid was being filtered. The same goes for
 Grid column select events. (See
 https://issues.apache.org/jira/browse/TAP5-2297)
 
 There are workarounds, but with a context I think we wouldn't need them:
 
 1. Use @Persist. Well, we all try to avoid this.
 
 2. Include C's parameters in the page's context and make sure they're
 passed down through every nested component down to C. But surely that's
 not
 reasonable. What if the page is concerned with a Hospital, but in it our
 components drill down through a Ward to a Patient and C is concerned with
 the Patient's Diagnosis. Does it really make sense to pass diagnosisId in
 through the page context and down through all the in-between components?
 Following this logic, we could end up with every parameter of every
 component in the page context.
 
 3. Use activation request parameters, but it appears to me to be messy.
 @ActivationRequestParameters is only available at the page level, so
 again
 we have to pass them all the way down. Even if we do this, it's a
 nuisance
 to pass them all the way UP in the first place. And again we could end up
 with every parameter of every component being declared in the page.
 
 4. Perhaps C can get and set request parameters by hand, but why? Isn't a
 context better?
 
 Am I seeing an issue that doesn't exist? Is there a better way?
 
 Cheers,
 
 Geoff
 
 


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

Re: Discussion on all AJAX requests needing context

2014-03-15 Thread Geoff Callender 
Yes, I think it should be part of tapestry core.

As a nod to jquery you could simply call it on :-)

On 15/03/2014, at 6:39 PM, Lance Java wrote:

 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.


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

Re: Discussion on all AJAX requests needing context

2014-03-14 Thread Geoff Callender 
I think column sorting also needs to pass context if, for instance, you're 
using a paged, filtered, GridDataSource. Without a context it might not build 
the next page correctly.

Bookmarking is a different issue, that I don't yet have a good solution for. 
For example, every EventLink has the page context baked into it when it's 
rendered. If events in other zones modify the page context, EventLinks outside 
those zones will not know the page context has changed. To address this, the 
event handlers must either refresh every component that can send a component 
event request (a zone around every EventLink?) or, for simplicity, refresh the 
whole page. If you're refreshing the whole page then the advantage of AJAX is 
kind of lost.

On 14/03/2014, at 8:16 PM, Dmitry Gusev wrote:

 I'd agree with context for the Grid component, though the only use-case I
 see for Grid's context is for paging event links, and it'd be nice and easy
 to support this.
 But Select component must be put into a Form, and forms have contexts, so I
 see no problems here.
 
 I don't think one should avoid using @Persist, it's just may be not the
 best choice for some use-cases using it with session scope.
 In such cases cookie-backed scope usually works well.
 
 Also I don't see any problems with your 2nd and 3rd workarounds. The
 question here is if you want to make the page state bookmark able, if you
 do -- you have to put this information to page's context (or page params).
 And you should be able to reconstruct the rest required parameters for all
 your components from page's context.
 
 
 
 
 On Fri, Mar 14, 2014 at 12:53 PM, Dusko Jovanovski dusk...@gmail.comwrote:
 
 You are absolutely right. Context for Select and Grid would be a welcome
 addition. Even though these are only scaffolding components that are meant
 to be extended and modified to fit your use cases, most people use them as
 they are. There may be some other components that need this addition, but
 none come to mind at the moment.
 
 
 On Fri, Mar 14, 2014 at 3:32 AM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 To all Tapestry devs,
 
 Please, I want your thoughts before I file a JIRA, just in case I have my
 wires crossed.
 
 I'm thinking that Tapestry has real problems working with complex AJAX
 pages because there are AJAX components that don't have a context
 parameter.
 
 The problem I see is that a deeply nested component, C, cannot handle an
 event from an AJAX sub-component unless C can reconstruct its context,
 ie.
 C has to be able to restore its parameters. This has been solved in Form
 and EventLink by giving them a context parameter. eg.
 
onPrepareForSubmit(Integer contextArg1) { etc. }
 
onMyevent(Integer contextArg1) { etc. }
 
 I routinely use this context to restore C's parameters, eg.
 
@Parameter
private Integer parameter1;
 
onPrepareForSubmit(Integer parameter1) {
this.parameter1 = parameter1;
}
 
 But what about Select and Grid? Neither of them has a context.
 
 Without a context, C can't handle 2 or more AJAX Select components. When
 one sends an event, C has no idea of the value of the other, nor of its
 own
 parameters. A context would fix all of this.
 
 Without a context, an inplace request from a GridPager can't remind C was
 currently selected or how the Grid was being filtered. The same goes for
 Grid column select events. (See
 https://issues.apache.org/jira/browse/TAP5-2297)
 
 There are workarounds, but with a context I think we wouldn't need them:
 
 1. Use @Persist. Well, we all try to avoid this.
 
 2. Include C's parameters in the page's context and make sure they're
 passed down through every nested component down to C. But surely that's
 not
 reasonable. What if the page is concerned with a Hospital, but in it our
 components drill down through a Ward to a Patient and C is concerned with
 the Patient's Diagnosis. Does it really make sense to pass diagnosisId in
 through the page context and down through all the in-between components?
 Following this logic, we could end up with every parameter of every
 component in the page context.
 
 3. Use activation request parameters, but it appears to me to be messy.
 @ActivationRequestParameters is only available at the page level, so
 again
 we have to pass them all the way down. Even if we do this, it's a
 nuisance
 to pass them all the way UP in the first place. And again we could end up
 with every parameter of every component being declared in the page.
 
 4. Perhaps C can get and set request parameters by hand, but why? Isn't a
 context better?
 
 Am I seeing an issue that doesn't exist? Is there a better way?
 
 Cheers,
 
 Geoff
 
 
 
 
 
 -- 
 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

Discussion on all AJAX requests needing context

2014-03-13 Thread Geoff Callender 
To all Tapestry devs,

Please, I want your thoughts before I file a JIRA, just in case I have my
wires crossed.

I'm thinking that Tapestry has real problems working with complex AJAX
pages because there are AJAX components that don't have a context parameter.

The problem I see is that a deeply nested component, C, cannot handle an
event from an AJAX sub-component unless C can reconstruct its context, ie.
C has to be able to restore its parameters. This has been solved in Form
and EventLink by giving them a context parameter. eg.

onPrepareForSubmit(Integer contextArg1) { etc. }

onMyevent(Integer contextArg1) { etc. }

I routinely use this context to restore C's parameters, eg.

@Parameter
private Integer parameter1;

onPrepareForSubmit(Integer parameter1) {
this.parameter1 = parameter1;
}

But what about Select and Grid? Neither of them has a context.

Without a context, C can't handle 2 or more AJAX Select components. When
one sends an event, C has no idea of the value of the other, nor of its own
parameters. A context would fix all of this.

Without a context, an inplace request from a GridPager can't remind C was
currently selected or how the Grid was being filtered. The same goes for
Grid column select events. (See
https://issues.apache.org/jira/browse/TAP5-2297)

There are workarounds, but with a context I think we wouldn't need them:

1. Use @Persist. Well, we all try to avoid this.

2. Include C's parameters in the page's context and make sure they're
passed down through every nested component down to C. But surely that's not
reasonable. What if the page is concerned with a Hospital, but in it our
components drill down through a Ward to a Patient and C is concerned with
the Patient's Diagnosis. Does it really make sense to pass diagnosisId in
through the page context and down through all the in-between components?
Following this logic, we could end up with every parameter of every
component in the page context.

3. Use activation request parameters, but it appears to me to be messy.
@ActivationRequestParameters is only available at the page level, so again
we have to pass them all the way down. Even if we do this, it's a nuisance
to pass them all the way UP in the first place. And again we could end up
with every parameter of every component being declared in the page.

4. Perhaps C can get and set request parameters by hand, but why? Isn't a
context better?

Am I seeing an issue that doesn't exist? Is there a better way?

Cheers,

Geoff

Does Grid need a context to participate in AJAX pages?

2014-02-24 Thread Geoff Callender 
To participate in nested components in an AJAX page we can utilise Form's, 
EventLink's, and ActionLink's context parameter. It can be used to pass the 
parameters of the enclosing component. The containing component's event 
handlers can receive the context and set its parameters from them before making 
any decisions. This works well.

However, Grid doesn't have a context parameter. Consequently, when the user 
chooses a new page in a GridPager, or a new sort order in a Grid column, the 
containing component doesn't know the context and consequently might not be 
able to render the Grid correctly.

I've produced an example, in which I've created a GridWithContext to wrap a 
Grid, and modified GridPager to include the context in its links and bubble up 
a new event with the context. It's in JumpStart 7.0 preview-6:

http://jumpstart.doublenegative.com.au/jumpstart7/

Without this, I would lose the selectedPersonId when I a GridPager link.

So I think Grid needs a context. Or is there another existing way to handle 
this problem?

There's an existing JIRA for this. 
https://issues.apache.org/jira/browse/TAP5-1162

Cheers,

Geoff


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

Re: Does Grid need a context to participate in AJAX pages?

2014-02-24 Thread Geoff Callender 
Sorry, the link should have been this:


http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons

On 24/02/2014, at 11:20 PM, Geoff Callender wrote:

 To participate in nested components in an AJAX page we can utilise Form's, 
 EventLink's, and ActionLink's context parameter. It can be used to pass the 
 parameters of the enclosing component. The containing component's event 
 handlers can receive the context and set its parameters from them before 
 making any decisions. This works well.
 
 However, Grid doesn't have a context parameter. Consequently, when the user 
 chooses a new page in a GridPager, or a new sort order in a Grid column, the 
 containing component doesn't know the context and consequently might not be 
 able to render the Grid correctly.
 
 I've produced an example, in which I've created a GridWithContext to wrap a 
 Grid, and modified GridPager to include the context in its links and bubble 
 up a new event with the context. It's in JumpStart 7.0 preview-6:
 
   http://jumpstart.doublenegative.com.au/jumpstart7/
 
 Without this, I would lose the selectedPersonId when I a GridPager link.
 
 So I think Grid needs a context. Or is there another existing way to handle 
 this problem?
 
 There's an existing JIRA for this. 
 https://issues.apache.org/jira/browse/TAP5-1162
 
 Cheers,
 
 Geoff
 


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

Re: Does Grid need a context to participate in AJAX pages?

2014-02-24 Thread Geoff Callender 
Yes, it's a workaround, and it has limitations which I mention in JumpStart 6 
where we were trying not to lose the filter's partialName:


http://jumpstart.doublenegative.com.au/jumpstart/together/ajaxcomponentscrud/persons

In that example:

@Property
// If we use @ActivationRequestParameter instead of @Persist, then our 
handler for filter form success would have
// to render more than just the listZone, it would have to render all other 
links and forms: it would need a zone
// around the Create... link so it could render it; and it would render 
the editorZone, which would be destructive
// if the user has been typing into Create or Update. Alternatively, it 
could use a custom JavaScript callback to
// update the partialName in all other links and forms - see 
AjaxResponseRenderer#addCallback(JavaScriptCallback).
@Persist
private String partialName;

Instead, I'm suggesting that if we make Grid behave like Form, EventLink, and 
ActionLink, then we won't need workarounds, as shown here:


http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons

Cheers,

Geoff

On 25/02/2014, at 12:10 AM, Dmitry Gusev wrote:

 Hi Geoff,
 
 another way to handle this situation (a workaround?) is by using
 @ActivationRequestParameter(paramName) attribute on page properties.
 This is what I do for my projects and what's working for me.
 
 
 
 On Mon, Feb 24, 2014 at 4:20 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 To participate in nested components in an AJAX page we can utilise Form's,
 EventLink's, and ActionLink's context parameter. It can be used to pass the
 parameters of the enclosing component. The containing component's event
 handlers can receive the context and set its parameters from them before
 making any decisions. This works well.
 
 However, Grid doesn't have a context parameter. Consequently, when the
 user chooses a new page in a GridPager, or a new sort order in a Grid
 column, the containing component doesn't know the context and consequently
 might not be able to render the Grid correctly.
 
 I've produced an example, in which I've created a GridWithContext to wrap
 a Grid, and modified GridPager to include the context in its links and
 bubble up a new event with the context. It's in JumpStart 7.0 preview-6:
 
http://jumpstart.doublenegative.com.au/jumpstart7/
 
 Without this, I would lose the selectedPersonId when I a GridPager link.
 
 So I think Grid needs a context. Or is there another existing way to
 handle this problem?
 
 There's an existing JIRA for this.
 https://issues.apache.org/jira/browse/TAP5-1162
 
 Cheers,
 
 Geoff
 
 
 -
 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: Suitability of AjaxResponseRenderer

2014-01-23 Thread Geoff Callender 
Thanks, Howard.

Rich Hickey is a very bright boy. When he identified complecting as a
pervasive problem in this business I thought hallelujah. He nailed it.


On 24 January 2014 05:44, Howard Lewis Ship hls...@gmail.com wrote:

 Got with the change. The MultiZoneUpdate return value is deprecated.  One
 of the things I've learned along the way is that having an API to call into
 (such as AjaxResponseRenderer) is sometimes a lot less complex than a magic
 mapping of return values.

 Rich Hickey's Simple Made Easy is a wake up call.


 On Wed, Jan 22, 2014 at 5:45 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:

  Ville, you've echoed my thoughts exactly. If I don't hear an alternative
  view in the next 24 hours then I'll go ahead with the change.
 
  Geoff
 
  On 22/01/2014, at 11:24 PM, Ville Virtanen wrote:
 
   Hi,
  
   my 2c: use addRenderer. The driving decision for me is to support case,
  where additional functionality is added later that uses
  ajaxResponseRenderer.addRenderer(zone). That does not mix well with the
  return value, and suddenly some part of ajax functionality is not
 working,
  and the bug manifests only if you happen to hit the code path that uses
 the
  return value. So, I see no point using the return value myself. (This
  however was tested with one of the alphas, I don't know if you can mix
 and
  match these days.)
  
   Ville Virtanen
   Orient Import Oy
   +358 45 111 4260
  
   -Alkuperäinen viesti-
   Lähettäjä: Geoff Callender [mailto:geoff.callender.jumpst...@gmail.com
 ]
   Lähetetty: 22. tammikuuta 2014 7:42
   Vastaanottaja: Tapestry development
   Aihe: Suitability of AjaxResponseRenderer
  
   Hey Howard (and anyone else who's qualified to answer),
  
   Before I mess up JumpStart by changing the examples that return
   zone.getBody() to use ajaxResponseRenderer.addRenderer(zone) instead,
 is
  there any downside to using the latter for single-zone updates?
  
   The reason I want to do this is to provide simple consistency between
  single-zone and multi-zone update examples. But is there a downside?
  
   Regards,
  
   Geoff
  
  
   -
   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

Re: Suitability of AjaxResponseRenderer

2014-01-22 Thread Geoff Callender 
Ville, you've echoed my thoughts exactly. If I don't hear an alternative view 
in the next 24 hours then I'll go ahead with the change.

Geoff

On 22/01/2014, at 11:24 PM, Ville Virtanen wrote:

 Hi,
 
 my 2c: use addRenderer. The driving decision for me is to support case, where 
 additional functionality is added later that uses 
 ajaxResponseRenderer.addRenderer(zone). That does not mix well with the 
 return value, and suddenly some part of ajax functionality is not working, 
 and the bug manifests only if you happen to hit the code path that uses the 
 return value. So, I see no point using the return value myself. (This however 
 was tested with one of the alphas, I don't know if you can mix and match 
 these days.)
 
 Ville Virtanen
 Orient Import Oy
 +358 45 111 4260
 
 -Alkuperäinen viesti-
 Lähettäjä: Geoff Callender [mailto:geoff.callender.jumpst...@gmail.com] 
 Lähetetty: 22. tammikuuta 2014 7:42
 Vastaanottaja: Tapestry development
 Aihe: Suitability of AjaxResponseRenderer
 
 Hey Howard (and anyone else who's qualified to answer),
 
 Before I mess up JumpStart by changing the examples that return
 zone.getBody() to use ajaxResponseRenderer.addRenderer(zone) instead, is 
 there any downside to using the latter for single-zone updates?
 
 The reason I want to do this is to provide simple consistency between 
 single-zone and multi-zone update examples. But is there a downside?
 
 Regards,
 
 Geoff
 
 
 -
 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

Suitability of AjaxResponseRenderer

2014-01-21 Thread Geoff Callender 
Hey Howard (and anyone else who's qualified to answer),

Before I mess up JumpStart by changing the examples that return
zone.getBody() to use ajaxResponseRenderer.addRenderer(zone) instead, is
there any downside to using the latter for single-zone updates?

The reason I want to do this is to provide simple consistency between
single-zone and multi-zone update examples. But is there a downside?

Regards,

Geoff

Re: What are the chances of date picker being fixed / upgraded for T5.4?

2013-09-18 Thread Geoff Callender 
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 trs...@gmail.com 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 AbstractTranslatorDate {



 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 lpri...@hope.nyc.ny.us
 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 trs...@gmail.com 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 lpri...@hope.nyc.ny.us
  wrote:
  
   High because we have to

Re: [jira] [Commented] (TAP5-2169) Core stack is not included by default

2013-09-18 Thread Geoff Callender 
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) j...@apache.org wrote:


 [
 https://issues.apache.org/jira/browse/TAP5-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

Re: Where have the 5.3.6 docs gone?

2013-05-05 Thread Geoff Callender 
Using current is no good because that's a moving target. Every version of 
JumpStart is based on a specific version of Tapestry so, naturally, its links 
to the API docs can't be to the current version.

How about having 5.3 API docs (as opposed to 5.3.6, 5.3.7, etc)?
 
On 04/05/2013, at 10:26 PM, Bob Harner wrote:

 This isn't directly answering your question, but... it would be best to
 link to the current URLs:
 
 http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/components/BeanDisplay.htmlhttp://tapestry.apache.org/5.3.6/apidocs/org/apache/tapestry5/corelib/components/BeanDisplay.html
 
 On Fri, May 3, 2013 at 8:51 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 For example, the current JumpStart is built against 5.3.6 and therefore
 has links to:
 
 
 http://tapestry.apache.org/5.3.6/apidocs/org/apache/tapestry5/corelib/components/BeanDisplay.html
 
 which is no longer there. Will the 5.3.6 docs be coming back?
 
 Cheers,
 
 Geoff
 -
 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: Where have the 5.3.6 docs gone?

2013-05-05 Thread Geoff Callender 
And that's the problem. People download old versions of JumpStart for old 
versions of Tapestry all the time. It would be quite unhelpful and misleading 
if the old versions had linked to the current stable release API instead of the 
API they relate to.

The release I put out today is expressly for T5.3. It should never link to 
T5.4, T5.5, T5.6, etc. API docs, but if I use current then that's what will 
happen.

Cheers,

Geoff

On 05/05/2013, at 6:40 PM, Massimo Lusetti wrote:

 Current is actually current stable release which means 5.3.7
 
 
 On Sun, May 5, 2013 at 9:40 AM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 Using current is no good because that's a moving target. Every version
 of JumpStart is based on a specific version of Tapestry so, naturally, its
 links to the API docs can't be to the current version.
 
 How about having 5.3 API docs (as opposed to 5.3.6, 5.3.7, etc)?
 
 On 04/05/2013, at 10:26 PM, Bob Harner wrote:
 
 This isn't directly answering your question, but... it would be best to
 link to the current URLs:
 
 
 http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/components/BeanDisplay.html
 
 http://tapestry.apache.org/5.3.6/apidocs/org/apache/tapestry5/corelib/components/BeanDisplay.html
 
 
 On Fri, May 3, 2013 at 8:51 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 For example, the current JumpStart is built against 5.3.6 and therefore
 has links to:
 
 
 
 http://tapestry.apache.org/5.3.6/apidocs/org/apache/tapestry5/corelib/components/BeanDisplay.html
 
 which is no longer there. Will the 5.3.6 docs be coming back?
 
 Cheers,
 
 Geoff
 -
 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
 
 
 
 
 -- 
 Massimo Lusetti


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

Re: Where have the 5.3.6 docs gone?

2013-05-05 Thread Geoff Callender 
A 5.3 symlink would be perfect.


On 6 May 2013 02:33, Massimo Lusetti mluse...@gmail.com wrote:

 On Sun, May 5, 2013 at 6:30 PM, Massimo Lusetti mluse...@gmail.com
 wrote:

 As you can see from our documentation page (
  http://tapestry.apache.org/documentation.html) there's no link for older
  docs. With older I mean before 5.3, for any release other then 5.3 you'll
  find docs, source and bin from the archive.
 
  Having said that we will see when 5.4 will be release if it will be the
  case to keep 5.3 docs online, at least for a while giving time libraries
  developer to update.
  But now if you want to stay up to date with 5.3 release branch you have
 to
  point to current or stable or tapestry5 symlinks.
  I think we could add a 5.3 symlink which point to 5.3 docs which btw
 are
  now equal to stable/current/tapestry5 ... That should suffice right?
 
 
 What I was trying to say is that I don't see feasible having online docs
 for every single release of 5.3 branch.

 --
 Massimo Lusetti

Where have the 5.3.6 docs gone?

2013-05-03 Thread Geoff Callender 
For example, the current JumpStart is built against 5.3.6 and therefore has 
links to:


http://tapestry.apache.org/5.3.6/apidocs/org/apache/tapestry5/corelib/components/BeanDisplay.html

which is no longer there. Will the 5.3.6 docs be coming back?

Cheers,

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

Re: Abstract layer or jquery all the way?

2012-10-26 Thread Geoff Callender 
I'm a bit lost in all of this. I thought an aim of 5.4 was to make it easy to 
use widgets from other JavaScript libraries, eg. the huge range of widgets in 
Ext JS, or any other library that gains traction? Is that still the case?

Geoff

On 27/10/2012, at 12:11 AM, Thiago H de Paula Figueiredo wrote:

 On Fri, 26 Oct 2012 10:47:35 -0200, trsvax trs...@gmail.com wrote:
 
 1. With things like mod_pagespeed now appearing it's not clear to me the
 work of optimizing page load times belongs in the framework. Since there is 
 a common solution development time might be better spent elsewhere.
 
 That's an Apache module and many people don't use it.
 
 2. Abstraction layers require a lot of work and in most cases never really 
 solve the problem. If developers are going to provide modules that have
 Javascript enabled components how would they be written? If they only use
 the abstraction layer then Tapestry will end up creating a complete
 Javascript framework.
 
 Nope, I don't think this is going to happen (creating a complete JavaScript 
 framework). Otherwise, it wouldn't be an abstraction layer. The Java 
 equivalent would be creating interfaces and have a jQuery implementation of 
 it, also a Prototype one.
 
 3. If someone wants to include an existing jQuery component they will need 
 the jQuery library anyway and if Tapestry really is going to head down the 
 Bootstrap path the Bootstrap components are jQuery components.
 
 That's the Bob Harner's point. What you said was valid for Prototype years 
 ago, is valid now, but it may not be valid in the next years. Again, we would 
 have people complaining that Tapestry uses a JavaScript framework that isn't 
 the best anymore.
 
 I have a large site that is not jQuery and for it backward compatibility is 
 very important. What I would like to see is the Javascript part become a
 module and you just pick the one you want and go.
 
 The abstraction layer would be needed for these modules to be written without 
 rewriting everything in jQuery and in Prototype.
 
 The two javascript modules
 I'd like to see are the old legacy Prototype one and a Bootstrap-jQuery one. 
 I don't see any benefit to an abstraction layer on the jQuery side. Many
 people know jQuery and it's well documented. Why introduce a layer that just 
 makes things more difficult?
 
 The abstraction layer is intended to be used mostly by Tapestry itself, 
 probably component libraries too. Your code using jQuery would work exactly 
 the same. Of course, people could use the abstraction layer too, but that's 
 up to them.
 
 -- 
 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: Abstract layer or jquery all the way?

2012-10-26 Thread Geoff Callender 
I can't find a definition of SPI in this mailing list. Is it:

- Service Provider Interface?
- Script Programming Interface?
- Single Page Interface?

I'm guessing it's #2. If so, then it sounds like an excellent idea, and I'm 
guessing it would have to be written in raw, vanilla javascript (the lowest 
common denominator) so that everyone can call it from their preferred flavour 
of javascript. 

As for the implementation beneath the SPI, sure, jQuery sounds as good a 
solution as any, and I see no harm in locking that in.

If I'm on track now, could someone post some examples/proposals of interface 
code, eg. the interface for Zone handling; so we can see what we're talking 
about?

Cheers,

Geoff

On 27/10/2012, at 3:48 AM, Massimo Lusetti wrote:

 On Fri, Oct 26, 2012 at 4:28 PM, Geoff Callender
 geoff.callender.jumpst...@gmail.com wrote:
 
 I'm a bit lost in all of this. I thought an aim of 5.4 was to make it easy 
 to use widgets from other JavaScript libraries, eg. the huge range of 
 widgets in Ext JS, or any other library that gains traction? Is that still 
 the case?
 
 
 That's the question Geoff, which I think a lot of people don't
 actually understand.
 
 The whole point here, in the tapestry javascript SPI, is to facilitate
 the ability to plug new components build on your favorite javascript
 library.
 
 There's no way to abstract a component behavior to let it be
 functional with all javascript libraries, in that case you should
 (must) write your own javascript component with your preferred
 javascript library, the SPI abstraction is there to facilitate the
 communication with the tapestry5 framework.
 
 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: Tapestry 5.3.5 BACK OUT Prototype 1.7.1?

2012-10-04 Thread Geoff Callender 
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

Fwd: Tapestry 5.3.5

2012-09-04 Thread Geoff Callender 
This bug messes up too many examples in JumpStart, so I won't be releasing a 
JumpStart for Tapestry 5.3.5.


On 02/09/2012, at 7:29 PM, Geoff Callender wrote:

 It looks like Zone highlight has stopped working, and zone slidedown and 
 slideup fail altogether (javascript error).
 
 It looks like it's caused by the upgrade to prototype 1.7.1.  I've logged it 
 in https://issues.apache.org/jira/browse/TAP5-1989 .
 
 Geoff
 
 On 31/08/2012, at 3:47 AM, Howard Lewis Ship wrote:
 
 Catch it while it's hot!  Yet another bug fix release for 5.3:
 
 Apache Tapestry 5.3.5
 
 http://tapestry.apache.org/2012/08/30/announcing-tapestry-535.html
 
 There may be an issue with DateField inside Internet Explorer that
 will have to be addressed in 5.3.6.  Since the switch from SVN to Git
 (and from Maven to Gradle) it has become much easier to backport fixes
 and generate releases.  We've created six releases since last November
 ... that's about one every two months.
 
 -- 
 Howard M. Lewis Ship
 
 Creator of Apache Tapestry
 
 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!
 
 (971) 678-5210
 http://howardlewisship.com
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 
 



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

Re: Desperately seeking a Tree example

2012-04-26 Thread Geoff Callender 
Thanks. I've put all I've learnt into a solution in latest JumpStart demo.

On 24/04/2012, at 12:18 AM, David Canteros wrote:

 PD: thanks to this example I have done something like to you are looking for
 
 --
 David Germán Canteros
 
 
 2012/4/23 David Canteros davidcanteros@gmail.com
 
 Hi Geoff,
 lombok page has one interesting example of Tree component, maybe is what
 you are looking for (I think)
 
 http://lombok.demon.co.uk/tapestry5Demo/test/core/treedemo
 
 
 This is the most clear example i have been seen until now, the other pages
 only shows the basic code.
 
 Rg
 
 --
 David Germán Canteros
 
 
 
 2012/4/23 Geoff Callender geoff.callender.jumpst...@gmail.com
 
 Hi Igor,
 
 Thanks, but I'm already familiar with those examples. I put a variation
 of the first one on the JumpStart site quite some time ago.
 
 So I guess what you're implying is that the use case I've described below
 is currently not possible?
 
 Geoff
 
 On 23/04/2012, at 9:30 PM, Igor Drobiazko wrote:
 
 There are some examples in tapestry-core's test app:
 
 
 http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/TreeDemo.java?view=markup
 
 
 http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/test/resources/org/apache/tapestry5/integration/app1/pages/TreeDemo.tml?view=markup
 
 and
 
 
 http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/TreeSelectionDemo.java?view=markup
 
 
 http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/test/resources/org/apache/tapestry5/integration/app1/pages/TreeSelectionDemo.tml?view=markup
 
 On Mon, Apr 23, 2012 at 1:17 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:
 
 Hi Devs,
 
 I have tried and tried but I just don't get how the Tree component is
 intended to be used.  I'm asking here because no-one over on the Users
 list
 seems to know either.
 
 I'm trying to make an example for JumpStart. The use case is simple:
 show
 a page with a Tree on the left and, when you select a leaf, display the
 related object on the right.
 
 Some sample code from someone who truly understands the Tree's
 capabilities and limitations would be greatly appreciated.
 
 Following that, I'd also like to understand how to make use of Tree's
 multiple selection capability. What's its intended purpose?
 
 Regards,
 
 Geoff
 -
 To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 
 
 
 --
 Best regards,
 
 Igor Drobiazko
 http://tapestry5.de
 http://twitter.com/drobiazko
 
 
 -
 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

Desperately seeking a Tree example

2012-04-23 Thread Geoff Callender 
Hi Devs,

I have tried and tried but I just don't get how the Tree component is intended 
to be used.  I'm asking here because no-one over on the Users list seems to 
know either.

I'm trying to make an example for JumpStart. The use case is simple: show a 
page with a Tree on the left and, when you select a leaf, display the related 
object on the right.

Some sample code from someone who truly understands the Tree's capabilities and 
limitations would be greatly appreciated.

Following that, I'd also like to understand how to make use of Tree's multiple 
selection capability. What's its intended purpose?

Regards,

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

Re: [VOTE] Release 5.3.3

2012-04-20 Thread Geoff Callender 
Geoff Callender: 0 (non-binding)

I find TAP5-1911 embarrassing. If 5.3.4 is expected to fix it in a couple of 
weeks then I'd vote +1, else -1.

Re: Stop SOPA

2012-01-13 Thread Geoff Callender 
+1

Geoff

On 14/01/2012, at 5:20 AM, Howard Lewis Ship wrote:

 I would like to see the Tapestry home page go black on January 18th,
 to show solidarity with everyone else who is opposed to this
 legislation.
 
 I'm thinking of changing the landing page to be white on black, with a
 popup lightbox dialog explaining why, with a link to
 http://americancensorship.org/
 
 Would anyone be opposed to 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
 
 -
 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

Chenillekit for T5.3?

2011-12-08 Thread Geoff Callender 
Any news on this? I've looked for a chenillekit mailing list but haven't found 
one that's working.

On 16/11/2011, at 12:37 AM, Massimo Lusetti wrote:

 On Tue, Nov 15, 2011 at 11:59 AM, Geoff Callender
 geoff.callender.jumpst...@gmail.com wrote:
 
 I can't test 5.3 because I can't find a compatible chenillekit. Is there a 
 new one around?
 
 Our source tree is in line with 5.3 but we were not able to produce a
 release yet.
 
 Sorry for the delay
 
 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: Decoding URL

2011-11-16 Thread Geoff Callender 
To find the Tapestry User List go to http://tapestry.apache.org/community.html .

Cheers,

Geoff

On 16/11/2011, at 7:26 AM, Thiago H. de Paula Figueiredo wrote:

 On Tue, 15 Nov 2011 18:03:10 -0200, Mike michael.ridin...@gmail.com wrote:
 
 I am a developer and must migrate an existing product to sole.
 
 Let me explain in other words: the Tapestry dev list is for discussing the 
 development of Tapestry, not with Tapestry. It's a place where committers and 
 other people who dive in the Tapestry source code discuss Tapestry code. Your 
 question is from a
 
 The relationship between the request uri and the content cannot be explained 
 by the vendor ... Duh?
 
 Who said the Tapestry team cannot explain that? We just said you asked in the 
 wrong place.
 
 ... So I figured who better to ask than the developers.  Any ideas?
 
 Read the users mailing list. You've already have two answers there. ;)
 
 -- 
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and 
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: dev-h...@tapestry.apache.org
 


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

Re: Decoding URL

2011-11-16 Thread Geoff Callender 
And for previous answers try 
http://tapestry.1045711.n5.nabble.com/Tapestry-User-f2375125.html .

On 16/11/2011, at 9:28 PM, Geoff Callender wrote:

 To find the Tapestry User List go to 
 http://tapestry.apache.org/community.html .
 
 Cheers,
 
 Geoff
 
 On 16/11/2011, at 7:26 AM, Thiago H. de Paula Figueiredo wrote:
 
 On Tue, 15 Nov 2011 18:03:10 -0200, Mike michael.ridin...@gmail.com wrote:
 
 I am a developer and must migrate an existing product to sole.
 
 Let me explain in other words: the Tapestry dev list is for discussing the 
 development of Tapestry, not with Tapestry. It's a place where committers 
 and other people who dive in the Tapestry source code discuss Tapestry code. 
 Your question is from a
 
 The relationship between the request uri and the content cannot be 
 explained by the vendor ... Duh?
 
 Who said the Tapestry team cannot explain that? We just said you asked in 
 the wrong place.
 
 ... So I figured who better to ask than the developers.  Any ideas?
 
 Read the users mailing list. You've already have two answers there. ;)
 
 -- 
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and 
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 


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

Re: So, are we ready for the vote?

2011-11-15 Thread Geoff Callender 
I can't test 5.3 because I can't find a compatible chenillekit. Is there a new 
one around?

On 15/11/2011, at 3:16 AM, Howard Lewis Ship wrote:

 Although there was a bit more last-minute scrambling in the RCs, I
 don't think anything too vastly troubling showed up. Are we ready for
 the 5.3 release vote?
 
 -- 
 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: So, are we ready for the vote?

2011-11-15 Thread Geoff Callender 
Thanks Massimo. I'm eagerly looking forward to it!

Cheers,

Geoff

On 16/11/2011, at 12:37 AM, Massimo Lusetti wrote:

 On Tue, Nov 15, 2011 at 11:59 AM, Geoff Callender
 geoff.callender.jumpst...@gmail.com wrote:
 
 I can't test 5.3 because I can't find a compatible chenillekit. Is there a 
 new one around?
 
 Our source tree is in line with 5.3 but we were not able to produce a
 release yet.
 
 Sorry for the delay
 
 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: Feedback from Tapestry users

2011-09-28 Thread Geoff Callender 
On the last point, IS TAPESTRY JUST TOO WIERD/ESOTERIC…, I suspect that the 
most useful thing I've done in JumpStart is something I did only a few days ago 
- adding a summary of what a page can do and how:


http://jumpstart.doublenegative.com.au/jumpstart/examples/navigation/whatiscalledandwhen

I did it because it occurred to me that I'd never come across such a summary in 
the Tapestry doco, and it felt like a bit of a revelation, pulling the 
fundamentals together into perspective!

Of course, maybe it's just me, and maybe I'll look at it in a week's time and 
think so what, but if others agree then perhaps something similar should go 
in the doco?

Cheers,

Geoff

On 28/09/2011, at 5:06 PM, antalk wrote:

 Hi Howard, and other readers,
 
 my 2 cents.. 
 
 MAKE IT EASIER TO DONATE COMPONENTS  CODE 
 
 Yes, but this has been discussed before a couple of times on this
 mailinglist, we definitely a central component / module hub where people can
 download and commit code to. Github is indeed the first candidate that comes
 to mind. We should not forget the Tapestry finder project
 (https://github.com/bobharner/Tapestry-finder)
 
 
 MOVE TOWARDS GREATER CLIENT-SIDE FOCUS 
 
 I concur with you that the basic ajax stuff is do-able without too much
 hassle but once you get into the dirty details (multizone updates, adding
 extra javascript calls) its gets quite complicated and you need deeper
 insight into the Tapestry internals. Which is what some users (in our
 company) dont want , they just want it to work and then point me at the
 Jquery stuff... telling me how hard can it be ?
 
 
 Which gets me to the latest point:
 
 IS TAPESTRY JUST TOO WIERD/ESOTERIC/ENLIGHTENED FOR SOME/MANY JAVA
 DEVELOPERS? 
 
 
 Yes, maybe for web developers that are used to other web frameworks (jsf,
 flash). I had the opportunity to find and select a web framework for our
 company and stumbled upon Tapestry and i liked it from the start. But other
 developers dont get (or dont want to get) the Tapestry way of thinking.
 
 And I dont really know what it is , because in the end , they can pump out
 web-apps (pages) faster than any other framework...
 
 It just some sort of hurdle you'll need to pass in order to fully embrace
 Tapestry.
 
 
 Good luck with 5.3 ! (im looking forward to it)
 
 
 
 
 
 
 
 --
 View this message in context: 
 http://tapestry.1045711.n5.nabble.com/Feedback-from-Tapestry-users-tp4847427p4848167.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: Thoughts: Should Ajax/Grid be that hard?

2011-09-20 Thread Geoff Callender 
Hi Taha,

Let's say there was a @SessionRequired annotation to put on methods. When 
session expires it redirects to a session expired page. But how would it 
determine whether session has expired vs. first time in? It would have to 
register sessions centrally somehow. More than that, it would have to register 
current page(s) within session, and remove them as you leave the page. Is that 
what you have in mind?

On 21/09/2011, at 12:05 AM, Taha Hafeez wrote:

 Hi Lenny
 
 I am using ajax grid in many of my applications. As I am using 5.2.6
 on some of the projects, I use my tapestry.js hack for it.
 
 The inability of grid to provide zone parameter (as others components
 do) instead of inplace is a limitation but I think this can be sorted
 out with the new ajax support.(I have not tried it yet but I think it
 can be done).
 
 Regarding session expiry, I think a simple redirect to a session
 expired page can be useful both for ajax and non-ajax situations.
 
 
 On Tue, Sep 20, 2011 at 1:24 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote:
 Hi guys,
 
 I just want to share my thoughts with you regarding my experience building 
 pretty simple infrastructure.
 Don't get me wrong, I love tapestry but I think there's definitely room for 
 improvement here.
 
 My goal was simple:  Develop a page that has an Ajax Grid that is backed by 
 a database table.
 
 To get this into somewhat decent shape it took about one man-month, which I 
 think could be improved.
 After a minor hiccup with JPA and problems with multiple database support, I 
 got the basic page up and
 running rather quickly. (kudos)
 Afterwards, I started noticing minor issues that took major time to fix.
 What I wound up with is a hodgepodge of hacks/workarounds to get everything 
 just right.
 Lots of JavaScript and event handling code.
 I believe that this stuff should work out of the box.
 
 It all boiled down to one major issue:
 Tapestry does not know how to deal with Ajax and expiring sessions.
 I would either get an error dialog, an exception, NULL data, or all of the 
 above when:
 - clicking on the Grid pager
 - clicking on a button that would update the grid (Ajax)
 
 Basically there are about 10 corner cases that deal with expired sessions 
 that
 were very hard to track down.
 
 All my hacks/workarounds do one thing:  When Ajax call is made,
 and the session is invalid (or new w/o SetupRender being called)
 I redirect to the same page, causing a reload or relogin if security 
 credentials also expired.
 
 I will try to post as much of this as I can as soon as I can on the wiki or 
 github or both,
 but I think this functionality should work out-of-the box.
 
 Thanks for the great product, and will be going into production soon.
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 
 
 
 
 -- 
 Regards
 
 Taha Hafeez Siddiqi (tawus)
 http://tawus.wordpress.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: [DISCUSS] Tapestry homepage redesign

2010-05-27 Thread Geoff Callender 
I agree with Uli for the reasons he mentions. The fact that you can see and 
take in the key points at a glance is a real drawcard. Time to replace the 
unicorn though? 

Nice work Robin.

On 27/05/2010, at 5:29 PM, Ulrich Stärk wrote:

 I still like No. 1 best. That's probably because of my preference for 
 fixed-width layouts. The content area is clearly delimited by the shadow 
 border, the key features are all visible at once and it's not obtrusive. The 
 banner might need some more tweaking, something feels odd about the green 
 background image, but I can't put a finger on it.
 
 Cheers,
 
 Uli
 
 On 26.05.2010 18:58, Robin Komiwes wrote:
 Fun :) On the first versions of Wooki, the title of the sample book when
 launching the application was :
 Tapestry 5 : When development meets Art
 http://github.com/robink/wooki/blob/7a3aaa0a9bd87856cab45fa1a012424423d9093d/src/main/java/com/wooki/services/StartupServiceImpl.java
 
 
 By the way, the first draft have moved.
 I'll now make new proposals by adding them into a subfolders
 Check http://komiwes.fr/tapestry
 
 Please note that it's still draft versions, don't worry about alignment
 and positioning problem at the moment.
 
 
 On Wed, May 26, 2010 at 6:46 PM, Thiago H. de Paula Figueiredo
 thiag...@gmail.com  wrote:
 
 On Wed, 26 May 2010 12:27:31 -0300, Christophe Cordenier
 christophe.corden...@gmail.com  wrote:
 
  As i am already a big fan of Robin's work, my opinion won't be much
 objective :)
 
 I have only one suggestion, A subtitle would be nice to express the
 Tapestry philosophy. I have though to 'Compose your Web Application'
 
 
 A slogan for Tapestry? Hum, nice idea! But I don't think 'Compose your Web
 Application' is good enough . . .
 
 This remembers something I read once: Tapestry is what JSF should have
 been. :P
 
  Development is Art !
 
 
 I agree 1000%. That's why my little company is named Ars Machina (ars =
 art, machina = machine)
 
 
 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
 and instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: dev-h...@tapestry.apache.org
 


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

Documentation of Deployment Notes: JBoss

2009-07-11 Thread Geoff Callender 

Hi,

I vote we reopen https://issues.apache.org/jira/browse/TAP5-576 until  
either the documentation at http://tapestry.apache.org/tapestry5/jboss.html 
 is corrected or the Tapestry classpath loading is changed to  
accommodate JBoss. One or the other needs to happen.


Cheers,

Geoff

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

Re: Documentation of Deployment Notes: JBoss

2009-07-11 Thread Geoff Callender 
Scratch that.  I see it's now covered in https://issues.apache.org/jira/browse/TAP5-693 
 .


On 11/07/2009, at 4:37 PM, Geoff Callender wrote:


Hi,

I vote we reopen https://issues.apache.org/jira/browse/TAP5-576  
until either the documentation at http://tapestry.apache.org/tapestry5/jboss.html 
 is corrected or the Tapestry classpath loading is changed to  
accommodate JBoss. One or the other needs to happen.


Cheers,

Geoff

-
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: [SUCCESS] Thiago H. de Paula Figueiredo as Tapestry Committer

2009-02-17 Thread Geoff Callender 
Great ideas and observations, Thiago. I especially like your points  
about adopting the Java EE transaction annotations (and I'd like to  
see a tapestry-jpa module), and modules for JFreeChart and  
JasperReports.


Geoff

On 17/02/2009, at 10:02 AM, Thiago H. de Paula Figueiredo wrote:


Hi!

I would like to thank all confidence you put on me. I'll do my best  
to not let you down. :)


It is a honor to me to join the Tapestry development team. I'm very  
passionate about this framework and I recommend it every time I get  
a chance. I've done two presentations about Tapestry in Belo  
Horizonte local events, one of them back in August, 2007. Even my  
professional life revolves around it. I worked a little with T4 and  
I'm a T5 user since T5.0.5, even earlier. I work part time in a  
commercial project that uses Tapestry and the Ars Machina Project (http://www.arsmachina.com.br/project 
), which includes some T5-related packages. I have some personal  
projects, all of them using Tapestry or having some relation to it.


By the way, I invite everyone to take a look at the Ars Machina  
Project, specially Tapestry CRUD. I started it as a way to provide  
some concepts that are not present in Tapestry, but, in my humble  
opinion, I think they would fit very well If you think it is worth,  
I'm willing to donate it or parts of it to the Tapestry project. All  
feedback is welcome, positive or negative.


I have a dream of having a full application stack built on Tapestry  
IoC, a little bit like Spring. I like Spring a lot, but T-IoC is  
awesome. At the same time, very easy and very powerful. With its  
distributed configuration and AOP support, T-IoC provides an almost  
perfect infrastructure for building truly convention-over- 
configuration, drop-a-JAR-in-the-classpath-and-it's-working packages  
and applications. The first steps is already done with Tapestry- 
Hibernate and its transaction support. But I think Tapestry would  
benefit a lot to have an implementation-agnostic transaction  
framework. We could reuse the Java EE transaction annotations for  
better compatibility.


We could also build some simple official integration with other  
frameworks like JFreeChart and JasperReports. Marketing-wise, we  
could attract more users when they visit the site and they read that  
their favorite frameworks are supported by Tapestry, even when we  
know how easy you can do the integration yourself.


Besides these larger projects, I also want to help the team to  
address some issues that could improve the Tapestry user experience.  
I also want to contribute to the documentation. Some questions in  
the mailing list are about things that are not easy to find in the  
docs.


See you!

--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

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




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

Re: JIRA formatting wiki-style not working

2009-02-09 Thread Geoff Callender 
I think the trick is to change the Renderer of fields like Comment  
from Default Text Renderer to Atlassian Wiki Renderer, as seen in this  
help page:


	http://www.atlassian.com/software/jira/docs/v3.12.3/issuefield_configuration.html 
 .


It's been a while since I've done it, but I think that's all there is  
to it.


Cheers,

Geoff

On 09/02/2009, at 11:12 AM, manuel aldana wrote:


I guess it is a tapestry jira project setup.

I had a look at another apache jira-project, and there it is  
switched on (https://issues.apache.org/jira/browse/GERONIMO-1680).  
Here you will see some markup and if you try to comment on this  
issue you will also see the preview option (right to the the input  
text box).


thanks.

Howard Lewis Ship schrieb:

I'm not sure what version of JIRA apache runs; I can look around to
see if there's an option to enable, but beyond that, it all has to go
through Apache's Infrastructure group.

On Sat, Feb 7, 2009 at 4:12 PM, manuel aldana ald...@gmx.de wrote:


hi,

I used some of the formatting meta-characters
(http://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all 
),
but they seem not to work in TAP jira. I also cannot see the  
preview-button.


Is text formatting for TAP jira switched off? Is there a reason  
for this (I
quite like to sparely use formatting in tickets, also code- 
snippets look

better)?

--
manuel aldana
ald...@gmx.de
software-engineering blog: http://www.aldana-online.de


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











--
manuel aldana
ald...@gmx.de
software-engineering blog: http://www.aldana-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

[jira] Commented: (TAP5-410) FormFragment with IE validates non-displayed fragments

2008-12-12 Thread Geoff Callender (JIRA) 

[ 
https://issues.apache.org/jira/browse/TAP5-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656227#action_12656227
 ] 

Geoff Callender commented on TAP5-410:
--

I was wrong - this is not just an IE issue.  It occurs in any browser if you 
submit the FormFragment before the page has finished loading.  The symptom is 
that client validation is bypassed but server validation of other (or all?) 
FormFragments occurs.

 FormFragment with IE validates non-displayed fragments
 --

 Key: TAP5-410
 URL: https://issues.apache.org/jira/browse/TAP5-410
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.0.17, 5.0.18
Reporter: Geoff Callender

 A user of JumpStart pointed this out in the wizard that uses FormFragments 
 http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/wizard/usingformfragments
 In this wizard each step is a separate FormFragment.  The sequence to make it 
 fail in IE 7 is: in step 1 enter a value and press Next, in step 2 (which is 
 a different fragment) press Prev without entering a value, in step 1 press 
 Next.  Kaboom! The validation error that is displayed belongs to step 2, not 
 step 1.
 This works fine in Safari 3.2.1 and Firefox 3.0.4 but not in IE 7.0.5730.13.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TAP5-410) FormFragment validates non-displayed fragments

2008-12-12 Thread Geoff Callender (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TAP5-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geoff Callender updated TAP5-410:
-

Description: 
A user of JumpStart pointed this out in the wizard that uses FormFragments 
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/wizard/usingformfragments

In this wizard each step is a separate FormFragment.  The sequence to make it 
fail in IE 7 is: in step 1 enter a value and press Next, in step 2 (which is a 
different fragment) press Prev without entering a value, in step 1 press Next.  
Kaboom! The validation error that is displayed belongs to step 2, not step 1.

This works fine in Safari 3.2.1 and Firefox 3.0.4 but not in IE 7.0.5730.13. 
[This statement is not true - see later comments].


  was:
A user of JumpStart pointed this out in the wizard that uses FormFragments 
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/wizard/usingformfragments

In this wizard each step is a separate FormFragment.  The sequence to make it 
fail in IE 7 is: in step 1 enter a value and press Next, in step 2 (which is a 
different fragment) press Prev without entering a value, in step 1 press Next.  
Kaboom! The validation error that is displayed belongs to step 2, not step 1.

This works fine in Safari 3.2.1 and Firefox 3.0.4 but not in IE 7.0.5730.13.


Summary: FormFragment validates non-displayed fragments  (was: 
FormFragment with IE validates non-displayed fragments)

 FormFragment validates non-displayed fragments
 --

 Key: TAP5-410
 URL: https://issues.apache.org/jira/browse/TAP5-410
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.0.17, 5.0.18
Reporter: Geoff Callender

 A user of JumpStart pointed this out in the wizard that uses FormFragments 
 http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/wizard/usingformfragments
 In this wizard each step is a separate FormFragment.  The sequence to make it 
 fail in IE 7 is: in step 1 enter a value and press Next, in step 2 (which is 
 a different fragment) press Prev without entering a value, in step 1 press 
 Next.  Kaboom! The validation error that is displayed belongs to step 2, not 
 step 1.
 This works fine in Safari 3.2.1 and Firefox 3.0.4 but not in IE 7.0.5730.13. 
 [This statement is not true - see later comments].

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (TAP5-410) FormFragment with IE validates non-displayed fragments

2008-12-11 Thread Geoff Callender (JIRA) 
FormFragment with IE validates non-displayed fragments
--

 Key: TAP5-410
 URL: https://issues.apache.org/jira/browse/TAP5-410
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.0.17, 5.0.18
Reporter: Geoff Callender


A user of JumpStart pointed this out in the wizard that uses FormFragments 
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/wizard/usingformfragments

In this wizard each step is a separate FormFragment.  The sequence to make it 
fail in IE 7 is: in step 1 enter a value and press Next, in step 2 (which is a 
different fragment) press Prev without entering a value, in step 1 press Next.  
Kaboom! The validation error that is displayed belongs to step 2, not step 1.

This works fine in Safari 3.2.1 and Firefox 3.0.4 but not in IE 7.0.5730.13.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release 5.0.18 as FINAL 5.0 release

2008-12-11 Thread Geoff Callender 

+0 (non-binding)
A JumpStart user has just found a validation problem with  
FormFragments in IE. Not sure if this should be considered an ugly  
enough error to avoid having in a Final release.  See https://issues.apache.org/jira/browse/TAP5-410 
 .


Regarding the _visit ASO problem (see below), I'll try to provide a  
simple example.  In the meantime, anyone can replicate it by  
downloading the current JumpStart (3.19.1), modifying the web/ 
build.xml and business.xml to get the T5.0.18 jars, then log in to the  
app and log out. It will fail right there.


Cheers,
Geoff

On 11/12/2008, at 12:11 AM, Ville Virtanen wrote:



Hi,

we have exactly the same setup - invalidate session + redirect to  
login,
and have no such problems. (Four production systems that I have  
played with

all seem to be fine.)

The documentation says:
Assigning a value to an ASO field will store that value. Assigning  
null to
an ASO field will remove the ASO (reading the field subsequently  
will force

a new ASO instance to be created).

so it is a bug if we can replicate. Can you provide simple page that
replicates this? (Two pages?)

- Ville


Geoff Callender-2 wrote:


Wow. I finally found time to take a closer look. The solution was to
do as Massimo did: nullify the _visit ASO before leaving the page.
This is a new requirement in 3.0.18.  the code worked fine before.

Is this is a side-effect of fixing
https://issues.apache.org/jira/browse/TAP5-399
 ?

Some more info - it seems it doesn't matter whether the _visit ASO is
nullified before invalidating the session or after  invalidating the
session - the important thing is to nullify it before returning.  I
have other non-null ASOs but I don't have to do anything with them.
I'd guess that this practise is required for any non-null ASO used in
the current page or perhaps the next rendered page.

On 10/12/2008, at 5:35 AM, Estevam Henrique Portela Mota e Silva  
wrote:



No problems using this piece of code, now I put it exactly as you
gave.

On Tue, Dec 9, 2008 at 9:48 AM, Geoff Callender [EMAIL PROTECTED]

wrote:



I wonder if the difference is that you're not redirecting to a new
page?


On 09/12/2008, at 11:42 PM, Estevam Henrique Portela Mota e Silva
wrote:

Geoff,


I've copied your code and applied it to my application, no
problems were
found. This is exactly what I did:

Src:

@Inject
private RequestGlobals requestGlobals;

@OnEvent(value = onActionFromIndex)
public void onActionFromLogoff(){
Session session =
requestGlobals.getRequest().getSession(false);
if(session != null){
_visit = null;
session.invalidate();
}
}

Are you sure that the problem is related only with this piece of
code?

On Tue, Dec 9, 2008 at 9:15 AM, Geoff Callender 
[EMAIL PROTECTED] wrote:

Is no-one else seeing this problem?  Is there an obvious solution
I've

missed?


On 08/12/2008, at 11:05 PM, Geoff Callender wrote:

-1 (non-binding)



My tests are failing on one thing only - I can't successfully
log out.

In my Layout component there's an ActionLink with id LogOut.
Here's the
event handler:

   Object onActionFromLogOut() {
   _logger.info(_visit.getMyLoginId() +  is logging
out.);
   Session session =
_requestGlobals.getRequest().getSession(false);
   if (session != null) {
   session.invalidate();
   }
   return LogIn.class;
   }

It results in the exception below.  If I comment out
session.invalidate();
then there is no exception.

22:55:12,591 INFO  [Layout] secofr is logging out.
22:55:12,597 ERROR [[default]] Servlet.service() for servlet
default
threw
exception
java.lang.IllegalStateException: Cannot create a session after  
the

response has been committed
   at
org.apache.catalina.connector.Request.doGetSession(Request.java:
2301)
   at
org.apache.catalina.connector.Request.getSession(Request.java:
2075)
   at

org
.apache
.catalina.connector.RequestFacade.getSession(RequestFacade.java:
833)
   at

org
.apache
.tapestry5
.internal.services.RequestImpl.getSession(RequestImpl.java:99)
   at $Request_11e16734cdd.getSession($Request_11e16734cdd.java)
   at $Request_11e16734c92.getSession($Request_11e16734c92.java)
   at

org
.apache
.tapestry5
.internal
.services
.SessionApplicationStatePersistenceStrategy
.requestDidComplete
(SessionApplicationStatePersistenceStrategy.java:126)
   at

org
.apache
.tapestry5
.internal
.services
.EndOfRequestListenerHubImpl
.fire(EndOfRequestListenerHubImpl.java:40)
   at

$
EndOfRequestListenerHub_11e16734ca9
.fire($EndOfRequestListenerHub_11e16734ca9.java)
   at

org.apache.tapestry5.services.TapestryModule
$3.service(TapestryModule.java:625)
   at
$
RequestHandler_11e16734cac
.service($RequestHandler_11e16734cac.java)
   at

org.apache.tapestry5.services.TapestryModule
$2.service(TapestryModule.java:611)
   at
$
RequestHandler_11e16734cac
.service($RequestHandler_11e16734cac.java)
   at

org
.apache
.tapestry5
.internal
.services.StaticFilesFilter.service

Re: [VOTE] Release 5.0.18 as FINAL 5.0 release

2008-12-11 Thread Geoff Callender 
It turns out that if an event handler invalidates the session, it has  
to nullify only those ASOs that it (the handler) has used.


Here's the requested example.  It fails unless we either:
(a) comment out the first line of onActionFromLogOut() because it  
references _myASO; or

(b) un-comment the line that sets _myASO to null.

It seems this is an unintended consequence of TAP5-399?


html xmlns:t=the usual xsd stuff
body
a t:type=actionlink t:id=LogOut href=#Log Out/a
/body
/html


package jumpstart.web.pages;

import org.apache.tapestry5.annotations.ApplicationState;
import org.apache.tapestry5.ioc.annotations.Inject;
import org.apache.tapestry5.services.RequestGlobals;
import org.apache.tapestry5.services.Session;

public class TestInvalidate {

@Inject
private RequestGlobals _requestGlobals;

@ApplicationState
private String _myASO;

void setupRender() {
_myASO = Everything's fine;
}

void onActionFromLogOut() {
System.out.println(_myASO =  + _myASO + .);

Session session = 
_requestGlobals.getRequest().getSession(false);
if (session != null) {
//  _myASO = null;
session.invalidate();
}
}
}


Cheers,
Geoff

On 11/12/2008, at 12:11 AM, Ville Virtanen wrote:


Hi,

we have exactly the same setup - invalidate session + redirect to  
login,
and have no such problems. (Four production systems that I have  
played with

all seem to be fine.)

The documentation says:
Assigning a value to an ASO field will store that value. Assigning  
null to
an ASO field will remove the ASO (reading the field subsequently  
will force

a new ASO instance to be created).

so it is a bug if we can replicate. Can you provide simple page that
replicates this? (Two pages?)

- Ville

Re: [VOTE] Release 5.0.18 as FINAL 5.0 release

2008-12-10 Thread Geoff Callender 
Wow. I finally found time to take a closer look. The solution was to  
do as Massimo did: nullify the _visit ASO before leaving the page.   
This is a new requirement in 3.0.18.  the code worked fine before.


Is this is a side-effect of fixing https://issues.apache.org/jira/browse/TAP5-399 
 ?


Some more info - it seems it doesn't matter whether the _visit ASO is  
nullified before invalidating the session or after  invalidating the  
session - the important thing is to nullify it before returning.  I  
have other non-null ASOs but I don't have to do anything with them.   
I'd guess that this practise is required for any non-null ASO used in  
the current page or perhaps the next rendered page.


On 10/12/2008, at 5:35 AM, Estevam Henrique Portela Mota e Silva wrote:

No problems using this piece of code, now I put it exactly as you  
gave.


On Tue, Dec 9, 2008 at 9:48 AM, Geoff Callender [EMAIL PROTECTED] 
wrote:


I wonder if the difference is that you're not redirecting to a new  
page?



On 09/12/2008, at 11:42 PM, Estevam Henrique Portela Mota e Silva  
wrote:


Geoff,


I've copied your code and applied it to my application, no  
problems were

found. This is exactly what I did:

Src:

 @Inject
 private RequestGlobals requestGlobals;

 @OnEvent(value = onActionFromIndex)
 public void onActionFromLogoff(){
 Session session =  
requestGlobals.getRequest().getSession(false);

 if(session != null){
 _visit = null;
 session.invalidate();
 }
 }

Are you sure that the problem is related only with this piece of  
code?


On Tue, Dec 9, 2008 at 9:15 AM, Geoff Callender 
[EMAIL PROTECTED] wrote:

Is no-one else seeing this problem?  Is there an obvious solution  
I've

missed?


On 08/12/2008, at 11:05 PM, Geoff Callender wrote:

-1 (non-binding)



My tests are failing on one thing only - I can't successfully  
log out.


In my Layout component there's an ActionLink with id LogOut.   
Here's the

event handler:

Object onActionFromLogOut() {
_logger.info(_visit.getMyLoginId() +  is logging  
out.);

Session session =
_requestGlobals.getRequest().getSession(false);
if (session != null) {
session.invalidate();
}
return LogIn.class;
}

It results in the exception below.  If I comment out
session.invalidate();
then there is no exception.

22:55:12,591 INFO  [Layout] secofr is logging out.
22:55:12,597 ERROR [[default]] Servlet.service() for servlet  
default

threw
exception
java.lang.IllegalStateException: Cannot create a session after the
response has been committed
at
org.apache.catalina.connector.Request.doGetSession(Request.java: 
2301)

at
org.apache.catalina.connector.Request.getSession(Request.java: 
2075)

at

org 
.apache 
.catalina.connector.RequestFacade.getSession(RequestFacade.java: 
833)

at

org 
.apache 
.tapestry5 
.internal.services.RequestImpl.getSession(RequestImpl.java:99)

at $Request_11e16734cdd.getSession($Request_11e16734cdd.java)
at $Request_11e16734c92.getSession($Request_11e16734c92.java)
at

org 
.apache 
.tapestry5 
.internal 
.services 
.SessionApplicationStatePersistenceStrategy 
.requestDidComplete 
(SessionApplicationStatePersistenceStrategy.java:126)

at

org 
.apache 
.tapestry5 
.internal 
.services 
.EndOfRequestListenerHubImpl 
.fire(EndOfRequestListenerHubImpl.java:40)

at

$ 
EndOfRequestListenerHub_11e16734ca9 
.fire($EndOfRequestListenerHub_11e16734ca9.java)

at

org.apache.tapestry5.services.TapestryModule 
$3.service(TapestryModule.java:625)

at
$ 
RequestHandler_11e16734cac 
.service($RequestHandler_11e16734cac.java)

at

org.apache.tapestry5.services.TapestryModule 
$2.service(TapestryModule.java:611)

at
$ 
RequestHandler_11e16734cac 
.service($RequestHandler_11e16734cac.java)

at

org 
.apache 
.tapestry5 
.internal 
.services.StaticFilesFilter.service(StaticFilesFilter.java:85)

at
$ 
RequestHandler_11e16734cac 
.service($RequestHandler_11e16734cac.java)

at

org.apache.tapestry5.internal.services.CheckForUpdatesFilter 
$2.invoke(CheckForUpdatesFilter.java:93)

at

org.apache.tapestry5.internal.services.CheckForUpdatesFilter 
$2.invoke(CheckForUpdatesFilter.java:84)

at

org 
.apache 
.tapestry5 
.ioc 
.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java: 
83)

at

org 
.apache 
.tapestry5 
.internal 
.services 
.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:106)

at
$ 
RequestHandler_11e16734cac 
.service($RequestHandler_11e16734cac.java)

at
$ 
RequestHandler_11e16734ca3 
.service($RequestHandler_11e16734ca3.java)

at

org.apache.tapestry5.services.TapestryModule 
$16.service(TapestryModule.java:1007)

at

org 
.apache 
.tapestry5 
.internal 
.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)

at

$ 
HttpServletRequestFilter_11e16734ca2 
.service($HttpServletRequestFilter_11e16734ca2.java

Re: [VOTE] Release 5.0.18 as FINAL 5.0 release

2008-12-09 Thread Geoff Callender 
Is no-one else seeing this problem?  Is there an obvious solution I've  
missed?


On 08/12/2008, at 11:05 PM, Geoff Callender wrote:


-1 (non-binding)

My tests are failing on one thing only - I can't successfully log out.

In my Layout component there's an ActionLink with id LogOut.  Here's  
the event handler:


Object onActionFromLogOut() {
_logger.info(_visit.getMyLoginId() +  is logging out.);
Session session = 
_requestGlobals.getRequest().getSession(false);
if (session != null) {
session.invalidate();
}
return LogIn.class;
}

It results in the exception below.  If I comment out  
session.invalidate(); then there is no exception.


22:55:12,591 INFO  [Layout] secofr is logging out.
22:55:12,597 ERROR [[default]] Servlet.service() for servlet default  
threw exception
java.lang.IllegalStateException: Cannot create a session after the  
response has been committed
	at org.apache.catalina.connector.Request.doGetSession(Request.java: 
2301)
	at org.apache.catalina.connector.Request.getSession(Request.java: 
2075)
	at  
org 
.apache 
.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
	at  
org 
.apache 
.tapestry5.internal.services.RequestImpl.getSession(RequestImpl.java: 
99)

at $Request_11e16734cdd.getSession($Request_11e16734cdd.java)
at $Request_11e16734c92.getSession($Request_11e16734c92.java)
	at  
org 
.apache 
.tapestry5 
.internal 
.services 
.SessionApplicationStatePersistenceStrategy 
.requestDidComplete(SessionApplicationStatePersistenceStrategy.java: 
126)
	at  
org 
.apache 
.tapestry5 
.internal 
.services 
.EndOfRequestListenerHubImpl.fire(EndOfRequestListenerHubImpl.java:40)
	at  
$ 
EndOfRequestListenerHub_11e16734ca9 
.fire($EndOfRequestListenerHub_11e16734ca9.java)
	at org.apache.tapestry5.services.TapestryModule 
$3.service(TapestryModule.java:625)
	at  
$RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)
	at org.apache.tapestry5.services.TapestryModule 
$2.service(TapestryModule.java:611)
	at  
$RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)
	at  
org 
.apache 
.tapestry5 
.internal.services.StaticFilesFilter.service(StaticFilesFilter.java: 
85)
	at  
$RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)
	at org.apache.tapestry5.internal.services.CheckForUpdatesFilter 
$2.invoke(CheckForUpdatesFilter.java:93)
	at org.apache.tapestry5.internal.services.CheckForUpdatesFilter 
$2.invoke(CheckForUpdatesFilter.java:84)
	at  
org 
.apache 
.tapestry5 
.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java: 
83)
	at  
org 
.apache 
.tapestry5 
.internal 
.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java: 
106)
	at  
$RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)
	at  
$RequestHandler_11e16734ca3.service($RequestHandler_11e16734ca3.java)
	at org.apache.tapestry5.services.TapestryModule 
$16.service(TapestryModule.java:1007)
	at  
org 
.apache 
.tapestry5 
.internal 
.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
	at  
$ 
HttpServletRequestFilter_11e16734ca2 
.service($HttpServletRequestFilter_11e16734ca2.java)
	at  
$ 
HttpServletRequestHandler_11e16734ca4 
.service($HttpServletRequestHandler_11e16734ca4.java)
	at  
$ 
HttpServletRequestHandler_11e16734ca1 
.service($HttpServletRequestHandler_11e16734ca1.java)
	at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java: 
179)
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235)
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at  
org 
.jboss 
.web 
.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235)
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at  
org 
.apache 
.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java: 
230)
	at  
org 
.apache 
.catalina.core.StandardContextValve.invoke(StandardContextValve.java: 
175)
	at  
org 
.jboss 
.web 
.tomcat 
.security 
.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
	at  
org 
.jboss 
.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
	at  
org 
.apache 
.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at  
org 
.apache 
.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at  
org 
.jboss 
.web 
.tomcat 
.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java: 
157)
	at  
org 
.apache 
.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java: 
109)
	at  
org 
.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 
262)
	at  
org 
.apache.coyote.http11.Http11Processor.process

Re: [VOTE] Release 5.0.18 as FINAL 5.0 release

2008-12-09 Thread Geoff Callender 

I wonder if the difference is that you're not redirecting to a new page?

On 09/12/2008, at 11:42 PM, Estevam Henrique Portela Mota e Silva wrote:


Geoff,

I've copied your code and applied it to my application, no problems  
were

found. This is exactly what I did:

Src:

   @Inject
   private RequestGlobals requestGlobals;

   @OnEvent(value = onActionFromIndex)
   public void onActionFromLogoff(){
   Session session =  
requestGlobals.getRequest().getSession(false);

   if(session != null){
   _visit = null;
   session.invalidate();
   }
   }

Are you sure that the problem is related only with this piece of code?

On Tue, Dec 9, 2008 at 9:15 AM, Geoff Callender 
[EMAIL PROTECTED] wrote:

Is no-one else seeing this problem?  Is there an obvious solution  
I've

missed?


On 08/12/2008, at 11:05 PM, Geoff Callender wrote:

-1 (non-binding)


My tests are failing on one thing only - I can't successfully log  
out.


In my Layout component there's an ActionLink with id LogOut.   
Here's the

event handler:

  Object onActionFromLogOut() {
  _logger.info(_visit.getMyLoginId() +  is logging  
out.);

  Session session =
_requestGlobals.getRequest().getSession(false);
  if (session != null) {
  session.invalidate();
  }
  return LogIn.class;
  }

It results in the exception below.  If I comment out  
session.invalidate();

then there is no exception.

22:55:12,591 INFO  [Layout] secofr is logging out.
22:55:12,597 ERROR [[default]] Servlet.service() for servlet  
default threw

exception
java.lang.IllegalStateException: Cannot create a session after the
response has been committed
  at
org.apache.catalina.connector.Request.doGetSession(Request.java: 
2301)

  at
org.apache.catalina.connector.Request.getSession(Request.java:2075)
  at
org 
.apache 
.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)

  at
org 
.apache 
.tapestry5 
.internal.services.RequestImpl.getSession(RequestImpl.java:99)

  at $Request_11e16734cdd.getSession($Request_11e16734cdd.java)
  at $Request_11e16734c92.getSession($Request_11e16734c92.java)
  at
org 
.apache 
.tapestry5 
.internal 
.services 
.SessionApplicationStatePersistenceStrategy 
.requestDidComplete 
(SessionApplicationStatePersistenceStrategy.java:126)

  at
org 
.apache 
.tapestry5 
.internal 
.services 
.EndOfRequestListenerHubImpl.fire(EndOfRequestListenerHubImpl.java: 
40)

  at
$ 
EndOfRequestListenerHub_11e16734ca9 
.fire($EndOfRequestListenerHub_11e16734ca9.java)

  at
org.apache.tapestry5.services.TapestryModule 
$3.service(TapestryModule.java:625)

  at
$ 
RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)

  at
org.apache.tapestry5.services.TapestryModule 
$2.service(TapestryModule.java:611)

  at
$ 
RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)

  at
org 
.apache 
.tapestry5 
.internal 
.services.StaticFilesFilter.service(StaticFilesFilter.java:85)

  at
$ 
RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)

  at
org.apache.tapestry5.internal.services.CheckForUpdatesFilter 
$2.invoke(CheckForUpdatesFilter.java:93)

  at
org.apache.tapestry5.internal.services.CheckForUpdatesFilter 
$2.invoke(CheckForUpdatesFilter.java:84)

  at
org 
.apache 
.tapestry5 
.ioc 
.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:83)

  at
org 
.apache 
.tapestry5 
.internal 
.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java: 
106)

  at
$ 
RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)

  at
$ 
RequestHandler_11e16734ca3.service($RequestHandler_11e16734ca3.java)

  at
org.apache.tapestry5.services.TapestryModule 
$16.service(TapestryModule.java:1007)

  at
org 
.apache 
.tapestry5 
.internal 
.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)

  at
$ 
HttpServletRequestFilter_11e16734ca2 
.service($HttpServletRequestFilter_11e16734ca2.java)

  at
$ 
HttpServletRequestHandler_11e16734ca4 
.service($HttpServletRequestHandler_11e16734ca4.java)

  at
$ 
HttpServletRequestHandler_11e16734ca1 
.service($HttpServletRequestHandler_11e16734ca1.java)

  at
org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java: 
179)

  at
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain 
.internalDoFilter(ApplicationFilterChain.java:235)

  at
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: 
206)

  at
org 
.jboss 
.web 
.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java: 
96)

  at
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain 
.internalDoFilter(ApplicationFilterChain.java:235)

  at
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: 
206)

  at
org 
.apache 
.catalina

Re: [VOTE] Release 5.0.18 as FINAL 5.0 release

2008-12-08 Thread Geoff Callender 

-1 (non-binding)

My tests are failing on one thing only - I can't successfully log out.

In my Layout component there's an ActionLink with id LogOut.  Here's  
the event handler:


Object onActionFromLogOut() {
_logger.info(_visit.getMyLoginId() +  is logging out.);
Session session = 
_requestGlobals.getRequest().getSession(false);
if (session != null) {
session.invalidate();
}
return LogIn.class;
}

It results in the exception below.  If I comment out  
session.invalidate(); then there is no exception.


22:55:12,591 INFO  [Layout] secofr is logging out.
22:55:12,597 ERROR [[default]] Servlet.service() for servlet default  
threw exception
java.lang.IllegalStateException: Cannot create a session after the  
response has been committed
	at org.apache.catalina.connector.Request.doGetSession(Request.java: 
2301)

at org.apache.catalina.connector.Request.getSession(Request.java:2075)
	at  
org 
.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java: 
833)
	at  
org 
.apache 
.tapestry5.internal.services.RequestImpl.getSession(RequestImpl.java:99)

at $Request_11e16734cdd.getSession($Request_11e16734cdd.java)
at $Request_11e16734c92.getSession($Request_11e16734c92.java)
	at  
org 
.apache 
.tapestry5 
.internal 
.services 
.SessionApplicationStatePersistenceStrategy 
.requestDidComplete(SessionApplicationStatePersistenceStrategy.java:126)
	at  
org 
.apache 
.tapestry5 
.internal 
.services 
.EndOfRequestListenerHubImpl.fire(EndOfRequestListenerHubImpl.java:40)
	at  
$ 
EndOfRequestListenerHub_11e16734ca9 
.fire($EndOfRequestListenerHub_11e16734ca9.java)
	at org.apache.tapestry5.services.TapestryModule 
$3.service(TapestryModule.java:625)
	at  
$RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)
	at org.apache.tapestry5.services.TapestryModule 
$2.service(TapestryModule.java:611)
	at  
$RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)
	at  
org 
.apache 
.tapestry5 
.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85)
	at  
$RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)
	at org.apache.tapestry5.internal.services.CheckForUpdatesFilter 
$2.invoke(CheckForUpdatesFilter.java:93)
	at org.apache.tapestry5.internal.services.CheckForUpdatesFilter 
$2.invoke(CheckForUpdatesFilter.java:84)
	at  
org 
.apache 
.tapestry5 
.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:83)
	at  
org 
.apache 
.tapestry5 
.internal 
.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:106)
	at  
$RequestHandler_11e16734cac.service($RequestHandler_11e16734cac.java)
	at  
$RequestHandler_11e16734ca3.service($RequestHandler_11e16734ca3.java)
	at org.apache.tapestry5.services.TapestryModule 
$16.service(TapestryModule.java:1007)
	at  
org 
.apache 
.tapestry5 
.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java: 
62)
	at  
$ 
HttpServletRequestFilter_11e16734ca2 
.service($HttpServletRequestFilter_11e16734ca2.java)
	at  
$ 
HttpServletRequestHandler_11e16734ca4 
.service($HttpServletRequestHandler_11e16734ca4.java)
	at  
$ 
HttpServletRequestHandler_11e16734ca1 
.service($HttpServletRequestHandler_11e16734ca1.java)
	at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java: 
179)
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235)
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at  
org 
.jboss 
.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java: 
96)
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235)
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at  
org 
.apache 
.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java: 
230)
	at  
org 
.apache 
.catalina.core.StandardContextValve.invoke(StandardContextValve.java: 
175)
	at  
org 
.jboss 
.web 
.tomcat 
.security 
.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
	at  
org 
.jboss 
.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
	at  
org 
.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java: 
127)
	at  
org 
.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java: 
102)
	at  
org 
.jboss 
.web 
.tomcat 
.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java: 
157)
	at  
org 
.apache 
.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at  
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 
262)
	at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java: 
844)
	at org.apache.coyote.http11.Http11Protocol 
$Http11ConnectionHandler.process(Http11Protocol.java:583)
	at

Re: [VOTE] Release 5.0.17 - Release Candidate #2

2008-11-22 Thread Geoff Callender 

+1 (non-binding)

It's passed all my tests.

On 22/11/2008, at 10:44 AM, Howard Lewis Ship wrote:

I've created and uploaded a release of Tapestry 5.0.17, ready to be  
voted upon.


Please vote this one up to make it public.  We will have another round
of voting in about two weeks
to vet it as the GA release (assuming no roadblock issues come up).

The files are uploaded to:

http://people.apache.org/~hlship/tapestry-releases/

and a Maven repository:

http://people.apache.org/~hlship/tapestry-ibiblio-rsynch-repository/

Please examine these files to determine if a new preview release,
5.0.17, is ready.

I've also created a 5.0.17 tag in Subversion:

http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.0.17/

On a successful vote, I'll move the files from these directories to
the proper distribution directories.

Vote will run for three days; on success I'll move the voted artifacts
into place and send out appropriate notifications.

--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release 5.0.16 -- Release Candidate

2008-11-16 Thread Geoff Callender 

+1 (non-binding)

Thanks for the explanation, Howard.  One thing, though - why didn't my  
custom validator have the same problem?


http://localhost:8180/jumpstart/examples/input/creatingvalidators1

or if that site is not up then:

http://localhost:8080/jumpstart/examples/input/creatingvalidators1

Cheers,
Geoff

On 16/11/2008, at 4:24 PM, Howard Lewis Ship wrote:


Don't invoke FormSupport.addValidation() unless you have client-side
validation for your validator.  The name of the method, and
documentation, could be better.

On Sat, Nov 15, 2008 at 6:03 PM, Geoff Callender
[EMAIL PROTECTED] wrote:
I haven't created client-side validation for this translator, but  
that
hasn't previously been a problem. How do I stop it being a problem  
now?


On 16/11/2008, at 12:59 PM, Howard Lewis Ship wrote:

Looks like user error to me ... I only see the base set of  
JavaScript
files being loaded; where's you @IncludeJavaScriptLibrary  
annotation?

You can't expect the code to exist if its never been loaded!

On Sat, Nov 15, 2008 at 4:45 PM, Geoff Callender
[EMAIL PROTECTED] wrote:


That's fixed the email validator.  But what must I do to fix my  
custom

translator?
You can see the problem in action here:



http://jumpstart.doublenegative.com.au:8180/jumpstart/examples/input/creatingtranslators1

or if that site is not up try here:



http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/creatingtranslators1

Cheers,
Geoff

On 16/11/2008, at 8:09 AM, Howard Lewis Ship wrote:

OK, I've updated the maven artifacts, the site, and the  
downloads to

incude the TAP5-359 fix (the client-side warning about email
validation).

On Sat, Nov 15, 2008 at 9:56 AM, Howard Lewis Ship [EMAIL PROTECTED] 


wrote:


Ok, I'm producing a new 5.0.16 build now.


On Sat, Nov 15, 2008 at 9:12 AM, Howard Lewis Ship [EMAIL PROTECTED] 


wrote:


You are correct, looking at the code, there's an errant call  
to setup
client-side validation, even though there is no client-side  
validator.


Since the release is not yet public, I'll correct that and  
build a new

5.0.16.


On Thu, Nov 13, 2008 at 5:49 PM, Geoff Callender [EMAIL PROTECTED] 


wrote:


-1 (non-binding)
I must change my vote until someone confirms there is not a
validators
problem.

Can someone please try an input field with a required, email
validator
and
client-side validation turned on and confirm whether they,  
too, get a

red
error overlaying the top of the page saying something like  
Function

Tapestry.Validator.email() does not exist for field
'myEmailAddress'.

It's so distracting and clearly unsuitable for production.

Regards,
Geoff



Geoff Callender-3 wrote:


+0 (non-binding)

It's passed all of my tests but I'm seeing red messages at  
the top

of
some screens, eg.

 Function Tapestry.Validator.yesno() does not exist for field
'newToTapestry'.

I'm seeing it on the following page after upgrade to 5.0.16:




http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/creatingtranslators1

Does this just require a simple code change at my end?

Regards,
Geoff

On 11/11/2008, at 7:46 PM, Ted Steen wrote:


Ted Steen: +1 (non-binding)

2008/11/11 David Solis [EMAIL PROTECTED]:


David Solis: +1

On Mon, Nov 10, 2008 at 6:55 PM, Howard Lewis Ship
[EMAIL PROTECTED] wrote:


I've created and uploaded a release of Tapestry 5.0.16,  
ready to

be voted upon.

It's been two months since 5.0.15, and I've fixed over 80  
bugs.

I
think Tapestry 5.0.16 is of release candidate quality and  
it

should be
made publically available to verify its readiness to be  
the GA

release
as well.

The files are uploaded to:

http://people.apache.org/~hlship/tapestry-releases/

and a Maven repository:



http://people.apache.org/~hlship/tapestry-ibiblio-rsynch-repository/

Please examine these files to determine if a new preview  
release,

5.0.16, is ready, and of release candidate quality.

I've also created a 5.0.16 tag in Subversion:

http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/
5.0.16/

On a successful vote, I'll move the files from these  
directories

to
the proper distribution directories.

Vote will run for three days; on success I'll move the  
voted

artifacts
into place and send out appropriate notifications.

--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: dev- 
[EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional

Re: [VOTE] Release 5.0.16 -- Release Candidate

2008-11-15 Thread Geoff Callender 
That's fixed the email validator.  But what must I do to fix my custom  
translator?

You can see the problem in action here:


http://jumpstart.doublenegative.com.au:8180/jumpstart/examples/input/creatingtranslators1

or if that site is not up try here:


http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/creatingtranslators1

Cheers,
Geoff

On 16/11/2008, at 8:09 AM, Howard Lewis Ship wrote:


OK, I've updated the maven artifacts, the site, and the downloads to
incude the TAP5-359 fix (the client-side warning about email
validation).

On Sat, Nov 15, 2008 at 9:56 AM, Howard Lewis Ship  
[EMAIL PROTECTED] wrote:

Ok, I'm producing a new 5.0.16 build now.


On Sat, Nov 15, 2008 at 9:12 AM, Howard Lewis Ship  
[EMAIL PROTECTED] wrote:
You are correct, looking at the code, there's an errant call to  
setup
client-side validation, even though there is no client-side  
validator.


Since the release is not yet public, I'll correct that and build a  
new 5.0.16.



On Thu, Nov 13, 2008 at 5:49 PM, Geoff Callender [EMAIL PROTECTED]  
wrote:


-1 (non-binding)
I must change my vote until someone confirms there is not a  
validators

problem.

Can someone please try an input field with a required, email  
validator and
client-side validation turned on and confirm whether they, too,  
get a red
error overlaying the top of the page saying something like  
Function
Tapestry.Validator.email() does not exist for field  
'myEmailAddress'.


It's so distracting and clearly unsuitable for production.

Regards,
Geoff



Geoff Callender-3 wrote:


+0 (non-binding)

It's passed all of my tests but I'm seeing red messages at the  
top of

some screens, eg.

 Function Tapestry.Validator.yesno() does not exist for field
'newToTapestry'.

I'm seeing it on the following page after upgrade to 5.0.16:


http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/creatingtranslators1

Does this just require a simple code change at my end?

Regards,
Geoff

On 11/11/2008, at 7:46 PM, Ted Steen wrote:


Ted Steen: +1 (non-binding)

2008/11/11 David Solis [EMAIL PROTECTED]:

David Solis: +1

On Mon, Nov 10, 2008 at 6:55 PM, Howard Lewis Ship
[EMAIL PROTECTED] wrote:
I've created and uploaded a release of Tapestry 5.0.16, ready  
to

be voted upon.

It's been two months since 5.0.15, and I've fixed over 80  
bugs.  I

think Tapestry 5.0.16 is of release candidate quality and it
should be
made publically available to verify its readiness to be the GA
release
as well.

The files are uploaded to:

http://people.apache.org/~hlship/tapestry-releases/

and a Maven repository:

http://people.apache.org/~hlship/tapestry-ibiblio-rsynch-repository/

Please examine these files to determine if a new preview  
release,

5.0.16, is ready, and of release candidate quality.

I've also created a 5.0.16 tag in Subversion:

http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/
5.0.16/

On a successful vote, I'll move the files from these  
directories to

the proper distribution directories.

Vote will run for three days; on success I'll move the voted
artifacts
into place and send out appropriate notifications.

--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
View this message in context: 
http://n2.nabble.com/-VOTE--Release-5.0.16Release-Candidate-tp1483148p1496710.html
Sent from the Tapestry Developers mailing list archive at  
Nabble.com.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind





--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind





--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release 5.0.16 -- Release Candidate

2008-11-15 Thread Geoff Callender 
I haven't created client-side validation for this translator, but that  
hasn't previously been a problem. How do I stop it being a problem now?


On 16/11/2008, at 12:59 PM, Howard Lewis Ship wrote:


Looks like user error to me ... I only see the base set of JavaScript
files being loaded; where's you @IncludeJavaScriptLibrary annotation?
You can't expect the code to exist if its never been loaded!

On Sat, Nov 15, 2008 at 4:45 PM, Geoff Callender
[EMAIL PROTECTED] wrote:
That's fixed the email validator.  But what must I do to fix my  
custom

translator?
You can see the problem in action here:


http://jumpstart.doublenegative.com.au:8180/jumpstart/examples/input/creatingtranslators1

or if that site is not up try here:


http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/creatingtranslators1

Cheers,
Geoff

On 16/11/2008, at 8:09 AM, Howard Lewis Ship wrote:


OK, I've updated the maven artifacts, the site, and the downloads to
incude the TAP5-359 fix (the client-side warning about email
validation).

On Sat, Nov 15, 2008 at 9:56 AM, Howard Lewis Ship  
[EMAIL PROTECTED]

wrote:


Ok, I'm producing a new 5.0.16 build now.


On Sat, Nov 15, 2008 at 9:12 AM, Howard Lewis Ship [EMAIL PROTECTED] 


wrote:


You are correct, looking at the code, there's an errant call to  
setup
client-side validation, even though there is no client-side  
validator.


Since the release is not yet public, I'll correct that and build  
a new

5.0.16.


On Thu, Nov 13, 2008 at 5:49 PM, Geoff Callender [EMAIL PROTECTED]
wrote:


-1 (non-binding)
I must change my vote until someone confirms there is not a  
validators

problem.

Can someone please try an input field with a required, email  
validator

and
client-side validation turned on and confirm whether they, too,  
get a

red
error overlaying the top of the page saying something like  
Function
Tapestry.Validator.email() does not exist for field  
'myEmailAddress'.


It's so distracting and clearly unsuitable for production.

Regards,
Geoff



Geoff Callender-3 wrote:


+0 (non-binding)

It's passed all of my tests but I'm seeing red messages at the  
top of

some screens, eg.

   Function Tapestry.Validator.yesno() does not exist for field
'newToTapestry'.

I'm seeing it on the following page after upgrade to 5.0.16:



http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/creatingtranslators1

Does this just require a simple code change at my end?

Regards,
Geoff

On 11/11/2008, at 7:46 PM, Ted Steen wrote:


Ted Steen: +1 (non-binding)

2008/11/11 David Solis [EMAIL PROTECTED]:


David Solis: +1

On Mon, Nov 10, 2008 at 6:55 PM, Howard Lewis Ship
[EMAIL PROTECTED] wrote:


I've created and uploaded a release of Tapestry 5.0.16,  
ready to

be voted upon.

It's been two months since 5.0.15, and I've fixed over 80  
bugs.  I

think Tapestry 5.0.16 is of release candidate quality and it
should be
made publically available to verify its readiness to be the  
GA

release
as well.

The files are uploaded to:

http://people.apache.org/~hlship/tapestry-releases/

and a Maven repository:


http://people.apache.org/~hlship/tapestry-ibiblio-rsynch-repository/

Please examine these files to determine if a new preview  
release,

5.0.16, is ready, and of release candidate quality.

I've also created a 5.0.16 tag in Subversion:

http://svn.apache.org/viewvc/tapestry/tapestry5/tags/ 
releases/

5.0.16/

On a successful vote, I'll move the files from these  
directories to

the proper distribution directories.

Vote will run for three days; on success I'll move the voted
artifacts
into place and send out appropriate notifications.

--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
View this message in context:
http://n2.nabble.com/-VOTE--Release-5.0.16Release-Candidate-tp1483148p1496710.html
Sent from the Tapestry Developers mailing list archive at  
Nabble.com.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind





--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind





--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

Re: [VOTE] Release 5.0.16 -- Release Candidate

2008-11-14 Thread Geoff Callender 

I guess the same needs to be done to Tapestry's email validator.

On 14/11/2008, at 7:54 PM, Dmitry Gusev wrote:


I've solved the problem:

public void render(Field field, String message, MarkupWriter writer,
FormSupport formSupport) {
formSupport.addValidation(field, yesno, message, null);
}


You're adding validator that isn't in Tapestry.Validator

Try this instead:

public void render(Field field, String message, MarkupWriter writer,
FormSupport formSupport) {
		formSupport.addValidation(field, regexp, message, your yesno  
regexp);

}


This should solve the problem

On Fri, Nov 14, 2008 at 04:49, Geoff Callender [EMAIL PROTECTED]  
wrote:




-1 (non-binding)
I must change my vote until someone confirms there is not a  
validators

problem.

Can someone please try an input field with a required, email  
validator and
client-side validation turned on and confirm whether they, too, get  
a red

error overlaying the top of the page saying something like Function
Tapestry.Validator.email() does not exist for field  
'myEmailAddress'.


It's so distracting and clearly unsuitable for production.

Regards,
Geoff



Geoff Callender-3 wrote:


+0 (non-binding)

It's passed all of my tests but I'm seeing red messages at the top  
of

some screens, eg.

 Function Tapestry.Validator.yesno() does not exist for field
'newToTapestry'.

I'm seeing it on the following page after upgrade to 5.0.16:




http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/creatingtranslators1


Does this just require a simple code change at my end?

Regards,
Geoff

On 11/11/2008, at 7:46 PM, Ted Steen wrote:


Ted Steen: +1 (non-binding)

2008/11/11 David Solis [EMAIL PROTECTED]:

David Solis: +1

On Mon, Nov 10, 2008 at 6:55 PM, Howard Lewis Ship
[EMAIL PROTECTED] wrote:

I've created and uploaded a release of Tapestry 5.0.16, ready to
be voted upon.

It's been two months since 5.0.15, and I've fixed over 80  
bugs.  I

think Tapestry 5.0.16 is of release candidate quality and it
should be
made publically available to verify its readiness to be the GA
release
as well.

The files are uploaded to:

http://people.apache.org/~hlship/tapestry-releases/http://people.apache.org/%7Ehlship/tapestry-releases/ 



and a Maven repository:

http://people.apache.org/~hlship/tapestry-ibiblio-rsynch-repository/ 
http://people.apache.org/%7Ehlship/tapestry-ibiblio-rsynch-repository/ 



Please examine these files to determine if a new preview release,
5.0.16, is ready, and of release candidate quality.

I've also created a 5.0.16 tag in Subversion:

http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/
5.0.16/

On a successful vote, I'll move the files from these  
directories to

the proper distribution directories.

Vote will run for three days; on success I'll move the voted
artifacts
into place and send out appropriate notifications.

--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
View this message in context:
http://n2.nabble.com/-VOTE--Release-5.0.16Release-Candidate-tp1483148p1496710.html
Sent from the Tapestry Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
С уважением,
Дмитрий Гусев



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

5.0.16 doco already released

2008-11-14 Thread Geoff Callender 

Is this intentional?

Begin forwarded message:


From: Geoff Callender [EMAIL PROTECTED]
Date: 15 November 2008 11:53:11 AM
To: Tapestry users [EMAIL PROTECTED]
Subject: Re: T5.0.16 not in Apache Maven repository

The doco appears to have been released. The front page and component  
reference are for 5.0.16 (LinkSubmit is there) but the downloads  
page is still 5.0.15.



On 14/11/2008, at 11:59 PM, Ulrich Stärk wrote:


The vote is still running...

Cheers,

Uli

Thiago H. de Paula Figueiredo schrieb:
Em Fri, 14 Nov 2008 04:54:13 -0300, Ulrich Stärk  
[EMAIL PROTECTED] escreveu:

Thiago H. de Paula Figueiredo schrieb:
Am I missing something or should the Tapestry 5.0.16 JARs be  
available in the Apache Maven repository by now?


Well, not in the central or the snapshot repository. But they  
should be in the tapestry-ibiblio-rsynch-repository which they  
are not.
Tapestry 5.0.16 was already released (as the release notes page  
states), so I'm not talking about snapshots. Or was it not  
officially released yet?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TAP5-353) Volatile works in Loop but not in Grid

2008-11-13 Thread Geoff Callender (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TAP5-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geoff Callender updated TAP5-353:
-

Attachment: ExceptionWhenGridIsVolatileIn5.0.16.txt

 Volatile works in Loop but not in Grid
 --

 Key: TAP5-353
 URL: https://issues.apache.org/jira/browse/TAP5-353
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.0.15, 5.0.16
Reporter: Geoff Callender
 Attachments: ExceptionWhenGridIsVolatileIn5.0.16.txt


 I have written almost identical Java for examples of an editable Loop and an 
 editable Grid where the Loop example requires volatile=true but the Grid 
 example does not. Why the difference?
 If I set volatile=true in the Grid example then on submit I get an 
 exception of the t:row field being null.
 You can see the working Loop and Grid at:
  
 http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/tables/editableloop1
  
 http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/tables/editablegrid1
 I will attach the exception that occurs when Grid has volatile=true.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TAP5-353) Volatile works in Loop but not in Grid

2008-11-13 Thread Geoff Callender (JIRA) 
Volatile works in Loop but not in Grid
--

 Key: TAP5-353
 URL: https://issues.apache.org/jira/browse/TAP5-353
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.0.16, 5.0.15
Reporter: Geoff Callender


I have written almost identical Java for examples of an editable Loop and an 
editable Grid where the Loop example requires volatile=true but the Grid 
example does not. Why the difference?

If I set volatile=true in the Grid example then on submit I get an exception 
of the t:row field being null.

You can see the working Loop and Grid at:
 
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/tables/editableloop1
 
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/tables/editablegrid1

I will attach the exception that occurs when Grid has volatile=true.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release 5.0.16 -- Release Candidate

2008-11-13 Thread Geoff Callender 

-1 (non-binding)
I must change my vote until someone confirms there is not a validators
problem.

Can someone please try an input field with a required, email validator and
client-side validation turned on and confirm whether they, too, get a red
error overlaying the top of the page saying something like Function
Tapestry.Validator.email() does not exist for field 'myEmailAddress'.

It's so distracting and clearly unsuitable for production.

Regards,
Geoff 



Geoff Callender-3 wrote:
 
 +0 (non-binding)
 
 It's passed all of my tests but I'm seeing red messages at the top of  
 some screens, eg.
 
   Function Tapestry.Validator.yesno() does not exist for field  
 'newToTapestry'.
 
 I'm seeing it on the following page after upgrade to 5.0.16:
 
 
 http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/creatingtranslators1
 
 Does this just require a simple code change at my end?
 
 Regards,
 Geoff
 
 On 11/11/2008, at 7:46 PM, Ted Steen wrote:
 
 Ted Steen: +1 (non-binding)

 2008/11/11 David Solis [EMAIL PROTECTED]:
 David Solis: +1

 On Mon, Nov 10, 2008 at 6:55 PM, Howard Lewis Ship  
 [EMAIL PROTECTED] wrote:
 I've created and uploaded a release of Tapestry 5.0.16, ready to  
 be voted upon.

 It's been two months since 5.0.15, and I've fixed over 80 bugs.  I
 think Tapestry 5.0.16 is of release candidate quality and it  
 should be
 made publically available to verify its readiness to be the GA  
 release
 as well.

 The files are uploaded to:

 http://people.apache.org/~hlship/tapestry-releases/

 and a Maven repository:

 http://people.apache.org/~hlship/tapestry-ibiblio-rsynch-repository/

 Please examine these files to determine if a new preview release,
 5.0.16, is ready, and of release candidate quality.

 I've also created a 5.0.16 tag in Subversion:

 http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/ 
 5.0.16/

 On a successful vote, I'll move the files from these directories to
 the proper distribution directories.

 Vote will run for three days; on success I'll move the voted  
 artifacts
 into place and send out appropriate notifications.

 --
 Howard M. Lewis Ship

 Creator Apache Tapestry and Apache HiveMind

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://n2.nabble.com/-VOTE--Release-5.0.16Release-Candidate-tp1483148p1496710.html
Sent from the Tapestry Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release 5.0.16 -- Release Candidate

2008-11-12 Thread Geoff Callender 

+0 (non-binding)

It's passed all of my tests but I'm seeing red messages at the top of  
some screens, eg.


	Function Tapestry.Validator.yesno() does not exist for field  
'newToTapestry'.


I'm seeing it on the following page after upgrade to 5.0.16:


http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/creatingtranslators1

Does this just require a simple code change at my end?

Regards,
Geoff

On 11/11/2008, at 7:46 PM, Ted Steen wrote:


Ted Steen: +1 (non-binding)

2008/11/11 David Solis [EMAIL PROTECTED]:

David Solis: +1

On Mon, Nov 10, 2008 at 6:55 PM, Howard Lewis Ship  
[EMAIL PROTECTED] wrote:
I've created and uploaded a release of Tapestry 5.0.16, ready to  
be voted upon.


It's been two months since 5.0.15, and I've fixed over 80 bugs.  I
think Tapestry 5.0.16 is of release candidate quality and it  
should be
made publically available to verify its readiness to be the GA  
release

as well.

The files are uploaded to:

http://people.apache.org/~hlship/tapestry-releases/

and a Maven repository:

http://people.apache.org/~hlship/tapestry-ibiblio-rsynch-repository/

Please examine these files to determine if a new preview release,
5.0.16, is ready, and of release candidate quality.

I've also created a 5.0.16 tag in Subversion:

http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/ 
5.0.16/


On a successful vote, I'll move the files from these directories to
the proper distribution directories.

Vote will run for three days; on success I'll move the voted  
artifacts

into place and send out appropriate notifications.

--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TAP5-1) AJAX ActionLink exception if clicked as page loads

2008-11-05 Thread Geoff Callender (JIRA) 

[ 
https://issues.apache.org/jira/browse/TAP5-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12645188#action_12645188
 ] 

Geoff Callender commented on TAP5-1:


Indeed, that's what I ended up doing in that page.

 AJAX ActionLink exception if clicked as page loads
 --

 Key: TAP5-1
 URL: https://issues.apache.org/jira/browse/TAP5-1
 Project: Tapestry 5
  Issue Type: Bug
Affects Versions: 5.0.15
Reporter: Geoff Callender

 I have a page with 2 ActionLinks - the first link updates the whole page; the 
 second link specifies a zone. 
 If you click on the two links in quick succession then an exception is 
 thrown.  Alternatively, just Reload the page and click on the second link 
 before the page has finished reloading and you'll get the same exception.
 Here's the page, with source: 
 http://202.177.217.122:8080/jumpstart/examples/javascript/ajax
 Here's the exception:
 A component event handler method returned the value [EMAIL PROTECTED] Return 
 type org.apache.tapestry5.internal.structure.BlockImpl can not be handled. 
 Configured return types are java.lang.Class, java.lang.String, java.net.URL, 
 org.apache.tapestry5.Link, org.apache.tapestry5.StreamResponse, 
 org.apache.tapestry5.runtime.Component.
 I understand that Tapestry doesn't hook up zones etc. until the DOM is 
 loaded. It's also been suggested to check Request#isXhr in your event 
 handler to see if it's an AJAX request - if it's not you can't return a 
 Block, so you'll have to figure out another way to do what needs to be done.
 However, since this symptom will afflict every AJAX ActionLink 
 out-of-the-box, it would be nice if the framework handled it so we don't have 
 to code around it.
 Geoff

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TAP5-322) Update links to JumpStart because its site has moved

2008-11-05 Thread Geoff Callender (JIRA) 

[ 
https://issues.apache.org/jira/browse/TAP5-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12645322#action_12645322
 ] 

Geoff Callender commented on TAP5-322:
--

Many thanks on the quick response.

 Update links to JumpStart because its site has moved
 

 Key: TAP5-322
 URL: https://issues.apache.org/jira/browse/TAP5-322
 Project: Tapestry 5
  Issue Type: Task
  Components: documentation
Affects Versions: 5.0.15
Reporter: Geoff Callender
Assignee: Howard M. Lewis Ship
Priority: Critical
 Fix For: 5.0.16


 JumpStart has moved to http://jumpstart.doublenegative.com.au . 
 Please update the links to it on Tapestry 5 home page (source is 
 tapestry-project/src/site/apt/index.apt) and the Tapestry home page 
 (http://tapestry.apache.org/index.html).
 The old site was http://files.doublenegative.com.au/jumpstart . 
 It will be discontinued in early November 2008 (sorry about the short 
 notice). 
 Thanks, 
 Geoff

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TAP5-322) Update links to JumpStart because its site has moved

2008-11-04 Thread Geoff Callender (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TAP5-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geoff Callender updated TAP5-322:
-

   Priority: Critical  (was: Major)
Description: 
JumpStart has moved to http://jumpstart.doublenegative.com.au . 
Please update the link to it in the Tapestry doco 
(tapestry-project/src/site/apt/index.apt). 

It was at http://files.doublenegative.com.au/jumpstart . 
The old site will be discontinued in early November 2008 (sorry about the short 
notice). 

Thanks, 
Geoff

  was:
JumpStart has moved to http://jumpstart.doublenegative.com.au . 

It was at http://files.doublenegative.com.au/jumpstart . 
The old site will be discontinued in early November 2008 (sorry about the short 
notice). 

Please update the link to it in the Tapestry doco 
(tapestry-project/src/site/apt/index.apt). 

Thanks, 
Geoff


 Update links to JumpStart because its site has moved
 

 Key: TAP5-322
 URL: https://issues.apache.org/jira/browse/TAP5-322
 Project: Tapestry 5
  Issue Type: Task
  Components: documentation
Affects Versions: 5.0.15
Reporter: Geoff Callender
Priority: Critical

 JumpStart has moved to http://jumpstart.doublenegative.com.au . 
 Please update the link to it in the Tapestry doco 
 (tapestry-project/src/site/apt/index.apt). 
 It was at http://files.doublenegative.com.au/jumpstart . 
 The old site will be discontinued in early November 2008 (sorry about the 
 short notice). 
 Thanks, 
 Geoff

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TAP5-322) Update links to JumpStart because its site has moved

2008-11-04 Thread Geoff Callender (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TAP5-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geoff Callender updated TAP5-322:
-

Description: 
JumpStart has moved to http://jumpstart.doublenegative.com.au . 
Please update the links to it on Tapestry 5 home page (source is 
tapestry-project/src/site/apt/index.apt) and the Tapestry home page 
(http://tapestry.apache.org/index.html).

The old site was http://files.doublenegative.com.au/jumpstart . 
It will be discontinued in early November 2008 (sorry about the short notice). 

Thanks, 
Geoff

  was:
JumpStart has moved to http://jumpstart.doublenegative.com.au . 
Please update the link to it in the Tapestry doco 
(tapestry-project/src/site/apt/index.apt). 

It was at http://files.doublenegative.com.au/jumpstart . 
The old site will be discontinued in early November 2008 (sorry about the short 
notice). 

Thanks, 
Geoff


 Update links to JumpStart because its site has moved
 

 Key: TAP5-322
 URL: https://issues.apache.org/jira/browse/TAP5-322
 Project: Tapestry 5
  Issue Type: Task
  Components: documentation
Affects Versions: 5.0.15
Reporter: Geoff Callender
Priority: Critical

 JumpStart has moved to http://jumpstart.doublenegative.com.au . 
 Please update the links to it on Tapestry 5 home page (source is 
 tapestry-project/src/site/apt/index.apt) and the Tapestry home page 
 (http://tapestry.apache.org/index.html).
 The old site was http://files.doublenegative.com.au/jumpstart . 
 It will be discontinued in early November 2008 (sorry about the short 
 notice). 
 Thanks, 
 Geoff

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TAPESTRY-2716) Update links to JumpStart because its site has moved

2008-11-01 Thread Geoff Callender (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TAPESTRY-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geoff Callender updated TAPESTRY-2716:
--

Description: 
JumpStart has moved to http://jumpstart.doublenegative.com.au .

The old site will be discontinued in early November 2008 (sorry about the short 
notice).
The old address is http://files.doublenegative.com.au/jumpstart .

Please update the links to it in the Tapestry doco.

Thanks,
Geoff

  was:
JumpStart has moved to http://jumpstart.doublenegative.com.au/jumpstart .

The old site will be discontinued in early November 2008 (sorry about the short 
notice).
The old address is http://files.doublenegative.com.au/jumpstart .

Please update the links to it in the Tapestry doco.

Thanks,
Geoff


 Update links to JumpStart because its site has moved
 

 Key: TAPESTRY-2716
 URL: https://issues.apache.org/jira/browse/TAPESTRY-2716
 Project: Tapestry
  Issue Type: Task
  Components: Documentation
Affects Versions: 5.0.15
Reporter: Geoff Callender

 JumpStart has moved to http://jumpstart.doublenegative.com.au .
 The old site will be discontinued in early November 2008 (sorry about the 
 short notice).
 The old address is http://files.doublenegative.com.au/jumpstart .
 Please update the links to it in the Tapestry doco.
 Thanks,
 Geoff

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TAP5-322) Update links to JumpStart because its site has moved

2008-11-01 Thread Geoff Callender (JIRA) 
Update links to JumpStart because its site has moved


 Key: TAP5-322
 URL: https://issues.apache.org/jira/browse/TAP5-322
 Project: Tapestry 5
  Issue Type: Task
  Components: documentation
Reporter: Geoff Callender


JumpStart has moved to http://jumpstart.doublenegative.com.au . 

It was at http://files.doublenegative.com.au/jumpstart . 
The old site will be discontinued in early November 2008 (sorry about the short 
notice). 

Please update the link to it in the Tapestry doco 
(tapestry-project/src/site/apt/index.apt). 

Thanks, 
Geoff

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TAP5-322) Update links to JumpStart because its site has moved

2008-11-01 Thread Geoff Callender (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TAP5-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geoff Callender updated TAP5-322:
-

Affects Version/s: 5.0.15

 Update links to JumpStart because its site has moved
 

 Key: TAP5-322
 URL: https://issues.apache.org/jira/browse/TAP5-322
 Project: Tapestry 5
  Issue Type: Task
  Components: documentation
Affects Versions: 5.0.15
Reporter: Geoff Callender

 JumpStart has moved to http://jumpstart.doublenegative.com.au . 
 It was at http://files.doublenegative.com.au/jumpstart . 
 The old site will be discontinued in early November 2008 (sorry about the 
 short notice). 
 Please update the link to it in the Tapestry doco 
 (tapestry-project/src/site/apt/index.apt). 
 Thanks, 
 Geoff

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TAP5-238) Component reference for Grid's empty parameter is misleading; provide a good example

2008-10-29 Thread Geoff Callender (JIRA) 

[ 
https://issues.apache.org/jira/browse/TAP5-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12643471#action_12643471
 ] 

Geoff Callender commented on TAP5-238:
--

Hi Howard,

I really don't get this. Wy does it behave differently when I specify  
empty=block:empty compared to not specifying it at all (given that  
its default is also block:empty)?

Cheers,

Geoff





 Component reference for Grid's empty parameter is misleading; provide a good 
 example
 

 Key: TAP5-238
 URL: https://issues.apache.org/jira/browse/TAP5-238
 Project: Tapestry 5
  Issue Type: Bug
Reporter: Geoff Callender
Assignee: Howard M. Lewis Ship
Priority: Minor
 Fix For: 5.0.16


 Doco says default for empty is block:empty but this doesn't work.  If I 
 leave out the empty parameter then my block with id=empty is ignored and 
 the standard message about no data to display appears.  However, if I 
 specify empty=block:empty then my block is displayed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TAP5-303) When @Property generated accessor methods will overwrite user generated accessors then either warn the user or do not generate them.

2008-10-22 Thread Geoff Callender (JIRA) 

[ 
https://issues.apache.org/jira/browse/TAP5-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641781#action_12641781
 ] 

Geoff Callender commented on TAP5-303:
--

An error sounds good to me.

 When @Property generated  accessor methods will overwrite user generated 
 accessors then either warn the user or do not generate them.
 -

 Key: TAP5-303
 URL: https://issues.apache.org/jira/browse/TAP5-303
 Project: Tapestry 5
  Issue Type: Improvement
Reporter: Joel Halbert
Priority: Minor

 Occasionally I get  stung when I declare an @Property on my page and then at 
 some point later I create custom accessor methods for the property - which of 
 course are never invoked since the @Property generated code wipes over them.
 I realise this is pretty minor, and all of my own doing, but I think a small 
 amount of pain might be saved if T5 either:
 a) warns when @Property is declared at the same time as accessor methods for 
 the property are defined.
 b) does not generate accessor methods when user defined methods are already 
 present.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TAP5-242) Cannot submit when Form is around Grid

2008-10-17 Thread Geoff Callender (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TAP5-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geoff Callender resolved TAP5-242.
--

Resolution: Invalid

My mistake. The symptom was not caused by the checkbox.

 Cannot submit when Form is around Grid
 --

 Key: TAP5-242
 URL: https://issues.apache.org/jira/browse/TAP5-242
 Project: Tapestry 5
  Issue Type: Bug
Reporter: Geoff Callender
 Attachments: Application Exception.webarchive, server.log


 When Form is around a Grid a submit results in:
 Failure reading parameter 'source' of component 
 theapp/security/UserSearch:grid.columns.loop: 
 org.apache.tapestry5.ioc.internal.util.TapestryException
 ...snipped...
 Caused by: java.lang.NullPointerException
   at 
 org.apache.tapestry5.corelib.components.GridColumns.getColumnNames(GridColumns.java:226)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (TAP5-238) Default for Grid's empty parameter does not work

2008-10-17 Thread Geoff Callender (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TAP5-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geoff Callender reopened TAP5-238:
--


I think the documentation needs rewording then.  The way I read it, these two 
examples are functionally identical, yet the first one does not work (the empty 
block is ignored):

t:grid ... 
t:block t:id=emptyWhatever .../t:block
/t:grid

t:grid ... t:empty=block:empty 
t:block t:id=emptyWhatever .../t:block
/t:grid



 Default for Grid's empty parameter does not work
 

 Key: TAP5-238
 URL: https://issues.apache.org/jira/browse/TAP5-238
 Project: Tapestry 5
  Issue Type: Bug
Reporter: Geoff Callender
Assignee: Howard M. Lewis Ship
Priority: Minor

 Doco says default for empty is block:empty but this doesn't work.  If I 
 leave out the empty parameter then my block with id=empty is ignored and 
 the standard message about no data to display appears.  However, if I 
 specify empty=block:empty then my block is displayed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Created: (TAP5-264) Lack of direct support for named context parameters

2008-10-13 Thread Geoff Callender 
Absolutely - just go to the issue and click on Comment. If you can't  
log in it's no problem to create an account.


On 13/10/2008, at 8:45 PM, Joel Halbert wrote:

Would it be possible to add a comment to this request along the  
lines of:


Can we investigate using the @Persist(client) notation as a way  
of transparently storing named parameters across sessions, much in  
the same way as is done now, but with human friendly query string  
encodings for primitive types


Such that if one declares

@Persist(client)
String name;

then rather than it being encoded on to the query string as  
asjklnckjsndc09dc09j23oirnm3lknmsdcm.smdc  (etc  !)
it is simply encoded as name=value (or some similar variant, where  
ideally the encoding strategy can be user defined)


I hope this makes sense...!?

(I would add the comment myself but I believe only developers can do  
this?)


Thx,
Joel



Francois Armand (JIRA) wrote:

Lack of direct support for named context parameters
---

Key: TAP5-264
URL: https://issues.apache.org/jira/browse/TAP5-264
Project: Tapestry 5
 Issue Type: Improvement
   Affects Versions: 5.0.16
   Reporter: Francois Armand


T5 REST orientation make easy the mappin between url and  
resources, but it lack the possibility to add normal named  
parameters.


This one are quite handy when one's want to make big queries  
bookmarkable. For example, in a application that send email to  
dynamic mailing list build as the result of a search in the company  
user base, it would be great if each user can bookmark his most  
used filter/dynamic ml.


The implementation can fit quite well with the current T5  
implementation if we add a direct mapping of the kind :
In URL map=[string=string,string=string] becomes a  
MapString,String in onActivate. I think that we can limit the use  
of MapString,String (at least for 5.0).


For example :
http://foo/myT5app/mypage/normalcontext/ 
mycontextmap=[key1:value1,key2:value2]/othercontextparam

= in the Java code :
void onActivate(String normalcontext, MapString,String  
mycontextmap, String othercontextparam) {

 String username = normalcontext:
 String telephone = mycontextmap.get(key1); //let the user handle  
the type

 String email=mycontextmap.get(key2);
 String eqalityType=othercontextparam;
 
}




--
SU3 Analytics Ltd
61b Oxford Gardens
W10 5UJ
London

Tel: +44 20 8960 2634
Mob: +44 75 2501 0825
www.su3analytics.com

SU3 Analytics Ltd is a company registered in England and Wales under  
company number 06639473 at registered address 61b Oxford Gardens,  
London W10 5UJ, United Kingdom.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Issue Comment Edited: (TAP5-264) Lack of direct support for named context parameters

2008-10-13 Thread Geoff Callender (JIRA) 

[ 
https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639016#action_12639016
 ] 

geoffcallender edited comment on TAP5-264 at 10/13/08 3:39 AM:


If not @Persist(client), then perhaps @Persist(query) or @QueryParameter

Ideally you could specify a name to override the field name, eg. 

@QueryParameter(name = asc)
private boolean ascending;

giving a URL ending with ?asc=true


  was (Author: geoffcallender):
If not @Persist(client), then perhaps @Persist(query) or @QueryParameter

Ideally you could specify a name to override the field name, eg. 

@QueryParameter(strategy = query, name = asc)
private boolean ascending;

giving a URL ending with ?asc=true

  
 Lack of direct support for named context parameters
 ---

 Key: TAP5-264
 URL: https://issues.apache.org/jira/browse/TAP5-264
 Project: Tapestry 5
  Issue Type: Improvement
Affects Versions: 5.0.16
Reporter: Francois Armand

 T5 REST orientation make easy the mappin between url and resources, but it 
 lack the possibility to add normal named parameters.
 This one are quite handy when one's want to make big queries bookmarkable. 
 For example, in a application that send email to dynamic mailing list build 
 as the result of a search in the company user base, it would be great if each 
 user can bookmark his most used filter/dynamic ml.
 The implementation can fit quite well with the current T5 implementation if 
 we add a direct mapping of the kind :
 In URL map=[string=string,string=string] becomes a MapString,String in 
 onActivate. I think that we can limit the use of MapString,String (at least 
 for 5.0).
 For example :
 http://foo/myT5app/mypage/normalcontext/mycontextmap=[key1:value1,key2:value2]/othercontextparam
 = in the Java code :
 void onActivate(String normalcontext, MapString,String mycontextmap, String 
 othercontextparam) {
   String username = normalcontext:
   String telephone = mycontextmap.get(key1); //let the user handle the type
   String email=mycontextmap.get(key2);
   String eqalityType=othercontextparam;
   
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TAP5-264) Lack of direct support for named context parameters

2008-10-13 Thread Geoff Callender (JIRA) 

[ 
https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639007#action_12639007
 ] 

Geoff Callender commented on TAP5-264:
--

I question the use of the activation context for filter criteria.  

The activation context is great for passing object ids (or entity ids), and 
with database backed applications that is exactly what you'd be doing most of 
the time.  The notion behind REST is that each URL represents a resource, which 
is pretty much what ids represent too.

However, there's a persuasive argument for treating filter criteria differently 
- ie. putting them into the query string portion of the URL instead of in the 
context.  that argument is made here: 
http://blpsilva.wordpress.com/2008/04/05/query-strings-in-restful-web-services/

So you get a URL like this 
http://localhost:8080/myapp/mypage?firstname=Humptylastname=Dumpty
instead of this 
http://localhost:8080/myapp/mypage/firstname/Humpty/lastname/Dumpty

Yes, it's not that hard to build our own links, eg:

@Inject
private ComponentResources _componentResources;

@Inject
private Request _request;

public Link set(String firstName, String lastName) {
Link link = _componentResources.createPageLink(this.getClass(), true);

if (firstName != null) {
link.addParameter(firstname, firstName);
}
if (lastName != null) {
link.addParameter(lastname, lastName);
}

return link;
}

void onActivate() {
_firstName = _request.getParameter(firstname);
_lastName = _request.getParameter(lastname);
}

But I thoroughly agree that it would be good if T5 provided a formalised way of 
handling this difference that didn't involve us building our own Links.

For actual resource-style URLs (which is what REST is all about) it would be 
nice if we could simply turn on name/value/name/value URLs built automatically 
by Tapestry, but is it really necessary unless Tapestry is going to do the 
whole REST thing and handle PUT and DELETE operations.  That should be a 
different issue.

 Lack of direct support for named context parameters
 ---

 Key: TAP5-264
 URL: https://issues.apache.org/jira/browse/TAP5-264
 Project: Tapestry 5
  Issue Type: Improvement
Affects Versions: 5.0.16
Reporter: Francois Armand

 T5 REST orientation make easy the mappin between url and resources, but it 
 lack the possibility to add normal named parameters.
 This one are quite handy when one's want to make big queries bookmarkable. 
 For example, in a application that send email to dynamic mailing list build 
 as the result of a search in the company user base, it would be great if each 
 user can bookmark his most used filter/dynamic ml.
 The implementation can fit quite well with the current T5 implementation if 
 we add a direct mapping of the kind :
 In URL map=[string=string,string=string] becomes a MapString,String in 
 onActivate. I think that we can limit the use of MapString,String (at least 
 for 5.0).
 For example :
 http://foo/myT5app/mypage/normalcontext/mycontextmap=[key1:value1,key2:value2]/othercontextparam
 = in the Java code :
 void onActivate(String normalcontext, MapString,String mycontextmap, String 
 othercontextparam) {
   String username = normalcontext:
   String telephone = mycontextmap.get(key1); //let the user handle the type
   String email=mycontextmap.get(key2);
   String eqalityType=othercontextparam;
   
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TAP5-264) Lack of direct support for named context parameters

2008-10-13 Thread Geoff Callender (JIRA) 

[ 
https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639016#action_12639016
 ] 

Geoff Callender commented on TAP5-264:
--

If not @Persist(client), then perhaps @Persist(query) or @QueryParameter

Ideally you could specify a name to override the field name, eg. 

@QueryParameter(strategy = query, name = asc)
private boolean ascending;

giving a URL ending with ?asc=true


 Lack of direct support for named context parameters
 ---

 Key: TAP5-264
 URL: https://issues.apache.org/jira/browse/TAP5-264
 Project: Tapestry 5
  Issue Type: Improvement
Affects Versions: 5.0.16
Reporter: Francois Armand

 T5 REST orientation make easy the mappin between url and resources, but it 
 lack the possibility to add normal named parameters.
 This one are quite handy when one's want to make big queries bookmarkable. 
 For example, in a application that send email to dynamic mailing list build 
 as the result of a search in the company user base, it would be great if each 
 user can bookmark his most used filter/dynamic ml.
 The implementation can fit quite well with the current T5 implementation if 
 we add a direct mapping of the kind :
 In URL map=[string=string,string=string] becomes a MapString,String in 
 onActivate. I think that we can limit the use of MapString,String (at least 
 for 5.0).
 For example :
 http://foo/myT5app/mypage/normalcontext/mycontextmap=[key1:value1,key2:value2]/othercontextparam
 = in the Java code :
 void onActivate(String normalcontext, MapString,String mycontextmap, String 
 othercontextparam) {
   String username = normalcontext:
   String telephone = mycontextmap.get(key1); //let the user handle the type
   String email=mycontextmap.get(key2);
   String eqalityType=othercontextparam;
   
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TAPESTRY-2701) BeanDisplay formatting can be off in IE7 with short values

2008-10-12 Thread Geoff Callender (JIRA) 

[ 
https://issues.apache.org/jira/browse/TAPESTRY-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638828#action_12638828
 ] 

Geoff Callender commented on TAPESTRY-2701:
---

Please add the following line to default.css.  It fixes the problem in IE 7 
(which throws the dd element onto the next line) without disturbing Firefox 3 
and Safari 3:

dl.t-beandisplay dd.id  { display:inline; margin-left: 0px; }   // IE 7

It does appear to be just the combination of dd with class=id and IE 7 that 
produces the problem.



 BeanDisplay formatting can be off in IE7 with short values
 --

 Key: TAPESTRY-2701
 URL: https://issues.apache.org/jira/browse/TAPESTRY-2701
 Project: Tapestry
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.0.15
Reporter: Geoff Callender

 I'm seeing strange formatting of BeanDisplay by IE7.  An example is the Id 
 line of this page, in which the dd element value is 1:
   http://202.177.217.122:8080/jumpstart/examples/output/easy
 I'm guessing IE7 has formatting issues with the dt/dd elements.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  1   2   3   >