Re: Git, my huge commit, etc.

[Lance Java]

Hi Howard, does this mean that all future test cases should be in
groovy/spock?

I think it's fair to say that everyone committing patches to Jira will have
Java knowledge. Since a patch is more likely to be included if it has a test
case, I think you are limiting your potential committers by requiring that
test cases are written in spock/groovy.

My 2p.

Cheers,
Lance.

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Git-my-huge-commit-etc-tp5711062p5711296.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: activation context in Tapestry

[Lance Java]

You will need to imlpement a ValueEncoder and contribute it to the
ValueEncoderSource.

http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/ValueEncoder.html
http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ValueEncoderSource.html

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/activation-context-in-Tapestry-tp5713555p5713557.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Tapestry 5.1.0.5 to 5.2.6 migration. .html templates

[Lance Java]

Firstly, this question should be on the user's list (not the dev list).

To change template lookup behaviour, you will need to either override or
(more likely) decorate the ComponentResourceLocator.

http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/pageload/ComponentResourceLocator.html
http://tapestry.apache.org/tapestry-ioc-decorators.html

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Tapestry-5-1-0-5-to-5-2-6-migration-html-templates-tp5713624p5713716.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Multiple Spring beans of same interface

[Lance Java]

I think that the spring integration needs a bit of an overhaul. I seem to
remember that tapestry does not ignore abstract springs bean which can
also cause problems.

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Multiple-Spring-beans-of-same-interface-tp5714183p5714190.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Overriding the header of a grid and sorting

[Lance Java]

Firstly, you have asked this question on the wrong list (it should be on the
tapestry-user NOT tapestry-dev)

Secondly, if you add a message with a key propertyName-label, tapestry
will use that instead of generating a user friendly name from the property
name.

@see TapestryInternalUtils.defaultLabel(String id, Messages messages, String
propertyExpression)


Cheers,
Lance.



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Overriding-the-header-of-a-grid-and-sorting-tp5715990p5716010.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Serverside push

[Lance Java]

Hi Tapestry team,

As you may be aware, I've created a push implementation for tapestry [1]
based on CometD [2]. I have seen recently that both wicket and primefaces
are supporting push using atmosphere [3] which is far more portable than
CometD.

When I introduced tapestry-cometd, Howard mentioned that he was keen to
include something similar in tapestry [4]. More recently he has said that he
intends to include push support in tapestry by december [5].

So, before I go ahead and move from cometd to atmosphere, I'd like to know
whether the tapestry team plan to use my implementation as a basis for the
tapestry push functionality or if you plan to do a clean room implementation
(in which case I won't bother).

Cheers,
Lance.

[1] https://github.com/uklance/tapestry-cometd
[2] http://cometd.org/
[3] https://github.com/Atmosphere/atmosphere
[4]
http://tapestry.1045711.n5.nabble.com/Announcement-Beta-release-of-tapestry-cometd-td5714020.html
[5] https://speakerdeck.com/u/hlship/p/tapestry-5-dot-4-in-the-pipeline





--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Serverside-push-tp5716189.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: How to use jquery fullCalenar with Tapestry 5.3

[Lance Java]

The main requirements of fullcalendar is a feed of events (json) between a
start date and an end date [1]. Fullcalendar is very configurable but by
default, it will hit a URL of the form:
/someURL?start=1262332800end=1265011200

1. Create an event on your page which uses a JSONObject to return a
TextStreamResponse.
public StreamResponse onGetEvents(@RequestParameter(start) long start,
@RequestParameter(end) long end)

2. Use componentResources.createEventLink(getEvents) to generate the base
URL

3. Pass the URL to the client (via JavaScriptSupport) to configure the
fullcalendar.

[1] http://arshaw.com/fullcalendar/docs/event_data/events_json_feed/



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/How-to-use-jquery-fullCalenar-with-Tapestry-5-3-tp5716186p5716190.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Retrieveing specific desc from the base

[Lance Java]

Tapestry supports localization for templates, messages and assets. It will
firstly attempt to locate a resource for Romanian before falling back to the
default unlocalized resource.

http://tapestry.apache.org/assets.html
http://tapestry.apache.org/localization.html

If you'd like explicit control over which assets are being loaded you can
@Inject AssetSource
http://tapestry.apache.org/5.3.6/apidocs/org/apache/tapestry5/services/AssetSource.html



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Retrieveing-specific-desc-from-the-base-tp5717585p5717586.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Retrieveing specific desc from the base

[Lance Java]

In your pages / components

@Inject
private Locale locale;



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Retrieveing-specific-desc-from-the-base-tp5717585p5717589.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: 5.4 JavaScript: Explicit vs. Unobtrusive initialization

[Lance Java]

Sounds to me like a benchmark is needed to compare id lookup against full DOM
scan for data attributes on all the major browsers on small, medium and
large web pages.



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/5-4-JavaScript-Explicit-vs-Unobtrusive-initialization-tp5717787p5717811.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: 5.4 JavaScript: Explicit vs. Unobtrusive initialization

[Lance Java]

Here's a first attempt at benchmarking the differences:
http://jsfiddle.net/xPVy6/6/



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/5-4-JavaScript-Explicit-vs-Unobtrusive-initialization-tp5717787p5717818.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Translator with Localized texts

[Lance Java]

1. Pass ComponentMessagesSource and ThreadLocale to the YesNoTranslator
constructor

2.
public String toClient(Boolean flag) { 
Messages messages =
messagesSource.getApplicationCatalog(threadLocale.getLocale());
return (flag ? messages.get(boolean.true) :
messages.get(boolean.false); 
}

3. Add entries for boolean.true and boolean.false for your languages to your
root application message catalogues



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Translator-with-Localized-texts-tp5717981p5717983.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Javax mail in Tapestry

[Lance Java]

Firstly, you've asked this question on the tapestry-dev list when you should
have posted it on tapestry-users.

Secondly, you have asked two questions:
1. How do I handle a form in tapestry?
2. How do I send a mail using javax mail

Answers:
1. http://tapestry.apache.org/forms-and-validation.html
2. http://en.wikipedia.org/wiki/RTFM



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Javax-mail-in-Tapestry-tp5718005p5718007.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Javax mail in Tapestry

[Lance Java]

just having a laugh... no harshness intended ;)



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Javax-mail-in-Tapestry-tp5718005p5718011.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Infinite Scroll Pagination with Tapestry

[Lance Java]

I really like the infinite-scroll approach: http://www.infinite-scroll.com/
This library gracefully degrades when javascript is disabled so is also good
for SEO[1]. You initially render links to all your pages and then the
infinite-scroll script hides the page navigation and replaces it with
scrolling.

Taha has recently blogged about integrating tapestry with ScrollBeyond here:
http://tawus.wordpress.com/2012/11/25/scrolling-pages-tapestry5-onscrollbeyond/

[1] http://en.wikipedia.org/wiki/Search_engine_optimization



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Infinite-Scroll-Pagination-with-Tapestry-tp5718284p5718285.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: JS changes merged to master branch

[Lance Java]

 Some day, scrap the SeleniumTests and replace with Geb! 
I've found selenium testing to be flaky at best. I'm interested to hear your
thoughts on what Geb will solve since it uses selenium's WebDriver under the
hood. Does Geb have better mechanisms for waiting for the client to be in a
particular state? With selenium, I sometimes find myself resorting to
Thread.sleep() which I hate.



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/JS-changes-merged-to-master-branch-tp5718747p5718772.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Getting current tapestry 5.4-SNAPSHOT head running in eclipse with git and gradle

[Lance Java]

Don't use ./gradlew eclipse as gradle will not keep the eclipse project
up-to-date with any changes.

I haven't used the gradle tooling in eclipse but I'm assuming it's similar
to the maven tooling. Instead of import existing project into eclipse
there should be an option to import existing gradle project or similar.



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Getting-current-tapestry-5-4-SNAPSHOT-head-running-in-eclipse-with-git-and-gradle-tp5718810p5718811.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Getting current tapestry 5.4-SNAPSHOT head running in eclipse with git and gradle

[Lance Java]

There's also this:
http://tapestry.apache.org/building-tapestry-from-source.html



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Getting-current-tapestry-5-4-SNAPSHOT-head-running-in-eclipse-with-git-and-gradle-tp5718810p5718812.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Tapestry 5 developer rates

[Lance Java]

I'm in London... It seems that Spring MVC and JSF are the norm wherever I go
(contractor / banking). I've never seen an advertised role mentioning
Tapestry :(



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Tapestry-5-developer-rates-tp5718832p5718839.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Submitting a value from a Form

[Lance Java]

Never use ${...} in attributes.

Use  t:value=transactionQuote.pickupQuoteID instead and tapestry will
create two way property binding which it can then get() and set().



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Submitting-a-value-from-a-Form-tp5718882p5718886.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: Submitting a value from a Form

[Lance Java]

By the way... the tapestry-dev list is for developers of tapestry. Messages
such as this should be posted on the tapestry-users list.



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Submitting-a-value-from-a-Form-tp5718882p5718887.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

Re: About GSoC 2013 Idea page

[Lance Java]

I think an interesting project would be to get Tapestry running on Netty
instead of a servlet container. I know that the play framework can run on
both and since 99% of tapestry is coded to it's own custom request, response
and session interfaces it wouldn't be that hard.

http://netty.io/
http://www.playframework.com/




--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/About-GSoC-2013-Idea-page-tp5720315p5720382.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.

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

[VOTE] Lance Semmens as a committer

[Lance Java]

Thanks for your votes everyone. It's great to be part of the team.

Discussion: Future of tapestry-test friends.

[Lance Java]

My 2p.

I have had major headaches in the past maintaining selenium tests. The main
problems are getting selenium to wait until the client is in a certain
state. I found checking for AJAX responses or other custom conditions to be
very flaky. Sometimes the only solution was to Thread.sleep() which I
absolutely hate. Since geb is built on top of selenium, I can't see how it
solves the problem but maybe there's some funky logic that alleviates the
pain. I've ended up using selenium for simple sanity tests and never try to
get too involved because the maintenance cost is not worth it.

I must say that the spock testing in Tapestry originally put me off because
I had to learn yet another language (ie groovy). I've since learned groovy
and found it very simple to pick up. I think that groovy really excels in
testing where you can very succinctly test code without the noise that java
sometimes requires. So, Spock testing gets a big thumbs up from me but I
can see how it might put some people off.

Lance.

Re: Final call for TAP5-2070

[Lance Java]

You can have your cake and eat it!

It's valid for a 404 response to have a body and a content type.
On 31 Jul 2013 17:07, Massimo Lusetti mluse...@gmail.com wrote:

 On Wed, Jul 31, 2013 at 6:00 PM, Lenny Primak lpri...@hope.nyc.ny.us
 wrote:

 I would say no.
  The behavior in production.and development mode differences in general is
  a bad idea. This will preclude valid testing in development.
 
 
 It would be the same situation of the ExceptionReport page and it would go
 hand to hand with the excellent feedback given by the whole framework,
 let's read this way: Hey dev you're accessing page X which doesn't declare
 an activation context Y so this is considered an error and will result in a
 404 within production

 --
 Massimo Lusetti

Re: Proposal for a list of modules recommended by the Tapestry team

[Lance Java]

I prefer the idea of a registry where all tapestry add ons can get a
mention with the ability to have the community rate and give feedback. Let
the user decide whether the library is ok by croudsourcing feedback.

Re: [T5.4-a-22] Core stack being added to page non-HTML MarkupWriter-generated output

[Lance Java]

A workaround is to get a MarkupWriter instance from MarkupWriterFactory and
return a StreamResponse.

Re: [T5.4-a-22] Core stack being added to page non-HTML MarkupWriter-generated output

[Lance Java]

Hi Denis, my workaround was meant for Thiago since he's not using a
template.

You might find it difficult (near impossible) to invoke tapestry's template
rendering yourself. I think you'll need to patch the issue, this will
likely require tweaking the JavaScriptSupport MarkupRendererFilter that
is contributed to the MarkupRenderer (in TapestryModule).

Re: Radio button event

[Lance Java]

You might be interested in one of these mixins.

http://tapestry-stitch.uklance.cloudbees.net/oneventdemo
http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/onevent

Re: A couple of questions after playing around with T5.4 and the tapestry5-portlet bridge

[Lance Java]

I've never understood why you would want portlets in a tapestry app. Apart
from maybe integrating with legacy code.

What can a portlet give you that a tapestry component can not?

Re: VOTE: Tapestry 5.4-beta-1

[Lance Java]

+1 (non-binding)
 On 4 Dec 2013 23:01, Howard Lewis Ship hls...@gmail.com wrote:

 This is a vote, open to all committers, to create a beta release of
 Tapestry 5.4.

 This represents the point at which new functionality should no longer be
 added and, instead, the emphasis should be on bug fixing and documentation.

 Vote to run for three days.

 Howard M. Lewis Ship: +1 (binding)

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

Re: Loop and iterator

[Lance Java]

You can use two loops. Example here:

http://tapestry-stitch.uklance.cloudbees.net/gallerydemo
 On 29 Jan 2014 16:12, Dimitris Zenios dimitris.zen...@gmail.com wrote:

 Is it possible to make the loop component expose the iterator through a
 public method?

 There are situations where a mixin might want to use it.

 Best Regards
 Dimitris Zenios

Re: Discussion on all AJAX requests needing context

[Lance Java]

It's probably worth mentioning my onevent mixin here.

http://tapestry-stitch.uklance.cloudbees.net/oneventdemo

Sorry to toot my own horn but I think it greatly simplifies many ajax
interactions. It not only allows a context to be passed but it can also
send a list of clientside field values in the ajax request.

Currently you can only listen to one event per dom element. It would be
nice to improve it to attach multiple listeners to multiple a single dom
element.

Does anyone else think this should be part of tapestry core?

NB I think the onevent name is ambiguous. It could do with being renamed
to observe or listen.

Re: Discussion on all AJAX requests needing context

[Lance Java]

 Yes, I think it should be part of tapestry core.

Unfortunately it clashes a bit with the zone parameter in select. Does
anybody support making a breaking change to remove the ajax behaviour from
select if this mixin was added to core?

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

Yeah, I thought about that but didn't feel it was descriptive enough.

TAP5-2273: Where would TapestryIOCJUnit4ClassRunner live?

[Lance Java]

I'd like to create a JUnit4ClassRunner to simplify integration testing of
Tapestry IOC services. More details here
https://issues.apache.org/jira/browse/TAP5-2273

I'm not sure which gradle module the test runner should live in?
tapestry-test is deprecated and tapestry-internal-test is not intended for
external use. Any suggestions?

Re: TAP5-2273: Where would TapestryIOCJUnit4ClassRunner live?

[Lance Java]

Hi Bob, I forgot to mention that I also feel that tapestry-test is a bit
heavy weight.

This junit runner is for testing tapestry-ioc apps. Tapestry-test has
transitive dependencies on tapestry-web, selenium, jetty etc. I'm not sure
people want all that on their classpath  when testing an IOC only app.

I'm beginning to think it belongs in it's own tapestry-ioc-test module.

Re: Discussion on AJAX requests need even more than a context?

[Lance Java]

Hi Geoff, I'm thinking this can also be done with the onevent mixin I
mentioned earlier. Since it can send a (configurable) list of clientside
field values to the serverside event, you can send all field values that
your event cares about.

If two fields (eg select menus, text fields) determine the behaviour, send
both.

Re: Discussion on AJAX requests need even more than a context?

[Lance Java]

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

Re: Discussion on AJAX requests need even more than a context?

[Lance Java]

That's an interesting concept. I like the sound of it.
 On 20 Mar 2014 09:22, Nourredine K. nourredin...@gmail.com wrote:

 Hi Geoff,

 Maybe the very interesting Dmitri's contribution can help here.
 It implements the publisher-subscriber pattern for Tapestry5
 pages/components.

 https://github.com/anjlab/anjlab-tapestry-commons/wiki/Publisher-API

 Nourredine.


 2014-03-19 13:45 GMT+01:00 Geoff Callender 
 geoff.callender.jumpst...@gmail.com:

  So it seems we're pretty much agreed that each AJAX-capable component
  needs a context parameter, which its containing component can use to
  restore its state (usually its parameters) before it makes any decisions.
 
 
 
 http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Discussion-on-all-AJAX-requests-needing-context-tt5726132.html
 
  But what if other components on the page need to know their state, too,
  before they can update their zoned contents?
 
  For example, a list of persons, L, in one part of the page might need to
  refresh itself whenever a person is edited in component E somewhere else
 on
  the page. That's easy (with a bit of bubbling up and perhaps some calls
  down, or perhaps a bit of pub-sub), unless L is filtered, like this:
 
 
 
 http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons
 
  E doesn't know about L or its filter, and nor should it, so the context
 on
  the submit in E will not contain filter info.
 
  In that example I found an OK-ish solution but I'm looking for a better
  way. The solution I found was to make L return javascript that submits
 the
  filter form. I made use of the fact that the client knows its state. But
  I'd prefer not to have that extra round-trip.
 
  So here's a crazy idea...
 
  What if, when the filter is submitted, we could do something like this:
 
  ajaxResponseRenderer.setQueryParameters(filter, filterValue);
 
  and Tapestry, client-side, would set that parameter on *every* Form,
  EventLink, Select, etc. in the page. That way, no matter what event
 request
  comes to the server, its request will be carrying the latest filter
 value.
  In the example above, L would always be able to find out the current
 filter:
 
  String filterValue = request.getParameter(filter);
 
  Crazy, right?
 
  I suppose that each component that wants to use this facility would need
 a
  way to tell Tapestry its initial values. Perhaps this could be
 declarative.
 
  Thoughts?
 
  Cheers,
 
  Geoff
  -
  To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
  For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 

Re: Discussion on AJAX requests need even more than a context?

[Lance Java]

I'm imagining the pub sub would work like...

public class L {
  @Inject
  private Publisher publisher;

  @Inject
  private Block someBlock;

  /**
   * Fired when the select menu changes
   */
  public Object onFilterChange(Entity entity) {
publisher.publish(changeEntity, entity);
return someBlock;
  }
}

public class E {
  @Inject
  private AjaxResponseRenderer ajaxResponseRenderer;

  @Inject
  private Zone someZone;

  @Property
  private Entity entity;

  @Subscribe(topic=changeEntity)
  void subscribeChangeEntity(Entity entity) {
 this.entity = entity;
 ajaxResponseRenderer.addRender(someZone;
  }
}

Re: Tapestry 5.4 and java8

[Lance Java]

Can't jarjar or similar do this via byte code transform automatically as
part of the build?
On 21 Mar 2014 16:40, Kalle Korhonen kalle.o.korho...@gmail.com wrote:

 On Fri, Mar 21, 2014 at 3:57 AM, Bob Harner bobhar...@gmail.com wrote:

  Kalle, can you list the steps you went through to do this? I'd like to
  document the process, since it isn't simply a matter of incrementing the
  version of a dependency.
 

 Sure. It was very simple actually:
 1) Have plastic module open on your favorite IDE
 2) Download an asm source release from http://forge.ow2.org/projects/asm/
 3) untar the asm source, move the source tree (starting from org) next to
 plastic/src/external/java
 4) delete the existing package org.apache.tapestry5.internal.plastic.asm
 5) use the IDE to rename the org.objectweb.asm package to
 org.apache.tapestry5.internal.plastic.asm
 6) fix compilation errors

 Naturally, your IDE needs to be smart enough to refactor the package names
 in the class files accordingly.

 Kalle



  On Mar 20, 2014 4:16 PM, Kalle Korhonen kalle.o.korho...@gmail.com
  wrote:
 
   Sure, no problem. We still need it released but that might have to wait
   till 5.4 GA release. Easy enough for those who need it to build it
   themselves though.
  
   Kalle
  
  
   On Thu, Mar 20, 2014 at 1:03 PM, Joachim Van der Auwera 
 li...@progs.be
   wrote:
  
THanks Kalle for doing this.
   
Kind regards,
Joachim
   
   
On 03/18/2014 08:32 PM, Joachim Van der Auwera wrote:
   
Java8 is now officially available.
ASM 5.0 has also been released (see http://forge.ow2.org/forum/
forum.php?forum_id=2302)
   
Could the ASM5 be integrated in Tapestry 5.4 and a new beta release
built? This way Tapestry could be used in Java8.
   
Kind regards,
Joachim
   
   
 -
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
   
   
   
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
   
   
  
 

Re: Discussion on AJAX requests need even more than a context?

[Lance Java]

Yes, you're right. You would need the current field values to be passed
along with the submit. @Persist cookie would work.

Or a mechanism like the onevent mixin would work where a list of field ids
is required and passed from client to server. But as you said, you don't
like this because one component needs knowledge of the other.

If the list of fields was passed from the containing page (or component)
I'm thinking it's ok. Perhaps each component could register it's fields
with the container so it's more transparent?
On 26 Mar 2014 00:49, Geoff Callender geoff.callender.jumpst...@gmail.com
wrote:

 Sorry, but I've read the solution below 10 times now and it hurts my head
 every time! :-) I don't see how it gets around the problem that when E is
 AJAX-submitted, the server-side elements can find ways to prod L to refresh
 but they cannot tell L the current value of F. The server-side doesn't know
 the current value of F, unless we make the server-side stateful (no thank
 you), or we somehow include the value of F in every request.

 What I'm aiming for is a solution which works declaratively. You know,
 where you don't see the plumbing. Just like @ActivationRequestParameter,
 but at the component level.

 On 21/03/2014, at 2:35 AM, Lance Java wrote:

  I'm imagining the pub sub would work like...
 
  public class L {
   @Inject
   private Publisher publisher;
 
   @Inject
   private Block someBlock;
 
   /**
* Fired when the select menu changes
*/
   public Object onFilterChange(Entity entity) {
 publisher.publish(changeEntity, entity);
 return someBlock;
   }
  }
 
  public class E {
   @Inject
   private AjaxResponseRenderer ajaxResponseRenderer;
 
   @Inject
   private Zone someZone;
 
   @Property
   private Entity entity;
 
   @Subscribe(topic=changeEntity)
   void subscribeChangeEntity(Entity entity) {
  this.entity = entity;
  ajaxResponseRenderer.addRender(someZone;
   }
  }


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

Jira Access

[Lance Java]

Hi Tapestry devs. I'm trying to assign a jira to myself but don't seem to
have the privileges. Can someone please give me dev rights in jira?
Username = Lance.

Thanks.

Re: Jira Access

[Lance Java]

Thanks, all good now.
 On 1 Apr 2014 17:07, Howard Lewis Ship hls...@gmail.com wrote:

 You should be good to go.


 On Tue, Apr 1, 2014 at 9:05 AM, Howard Lewis Ship hls...@gmail.com
 wrote:

  I'll take care of it.
 
 
  On Tue, Apr 1, 2014 at 1:02 AM, Lance Java lance.j...@googlemail.com
 wrote:
 
  Hi Tapestry devs. I'm trying to assign a jira to myself but don't seem
 to
  have the privileges. Can someone please give me dev rights in jira?
  Username = Lance.
 
  Thanks.
 
 
 
 
  --
  Howard M. Lewis Ship
 
  Creator of Apache Tapestry
 
  The source for Tapestry training, mentoring and support. Contact me to
  learn how I can get you up and productive in Tapestry fast!
 
  (971) 678-5210
  http://howardlewisship.com
 



 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

Re: WTF with the broken tests?

[Lance Java]

So sorry... I can appreciate that you're overstretched.
I've removed :tapestry-ioc-test from the build so that the build can pass
again
I'll fix the test tonight (UK time).


On 1 April 2014 23:40, Howard Lewis Ship hls...@gmail.com wrote:

 Please stop committing broken changes!

 It is extremely disrespectful to the other developers and their very full
 schedules to commit code that is broken. Ok, it's very disrespectful to me
 and my 150% over-taxed schedule.

 I've spent the last couple of hours fixing other people's bugs in the test
 suites.

 I'm trying to generate a beta-4 release.

 Any idea what this is about?

 :tapestry-ioc-test:test

 org.apache.tapestry5.ioc.test.TapestryIOCJUnit4ClassRunnerAfterClassTest 
 testInjectB FAILED
 java.lang.AssertionError at
 TapestryIOCJUnit4ClassRunnerAfterClassTest.java:51

 5 tests completed, 1 failed
 :tapestry-ioc-test:test FAILED

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

Re: Broken UTF-8 handling in tapestry 5.4 becomes show-stopper - please help

[Lance Java]

You could set -Dfile.encoding=UTF-8 when starting up the servlet container.
 On 8 Apr 2014 14:24, Michael Wyraz michael.wy...@evermind.de wrote:

 Hi,

 could please anyone with commit access fix this little issue
 https://issues.apache.org/jira/browse/TAP5-2219 or at least add the
 testcase to the testsuite? This becomes a show-stopper for us for migration
 to tapestry 5.4 since all pages with utf-8 chars fails on windows.

 Kind regards,
 Michael.


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

Re: Broken UTF-8 handling in tapestry 5.4 becomes show-stopper - please help

[Lance Java]

 It still would be great if this could be fixed :-)

Agreed, but I'm not convinced that hard coding UTF8 is the answer :)

Re: [VOTE] Jochen Kemnade as Tapestry Committer

[Lance Java]

Lance Semmens + 1 (non-binding)
 On 17 Apr 2014 22:41, Howard Lewis Ship hls...@gmail.com wrote:

 I've seen Jochen busy on the mailing list for quite some time, and even
 busier filing bugs and submitting patches. I think he'd make a fine
 addition to the team.

 Howard M. Lewis Ship: +1 (binding)

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com
 @hlship

Re: Accessing generic type information of bound parameters

[Lance Java]

 No, there is no way to access the generic type, this information is lost
during the compilation process.

That's not actually correct. Lets consider the following class:

public class MyClass {
   private ListFoo foos;

   public ListBar getBars() {
  ...
   }

   public void doStuffWithBaz() {
  ListBaz bazs = new ArrayListBaz();
  ...
   }
}

In this example, the ONLY generic that will be lost after compilation (due
to type erasure) is Baz. Both Foo and Bar ARE available at runtime.

@see
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Method.html#getGenericReturnType()
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#getGenericType()

Re: Accessing generic type information of bound parameters

[Lance Java]

Just having a quick poke through the code this could be fixed by adding the
following methods to the public API.

java.lang.reflect.Type PropertyConduit.getPropertyGenericType()
java.lang.reflect.Type Binding.getBindingGenericType()
java.lang.reflect.Type ComponentResources.getBoundGenericType(String
parameterName)

I'm guessing that only PropBinding would return a type from
getBindingGenericType(). All other bindings would return null.

TAP5-1213: Changes to public API

[Lance Java]

I'm looking into TAP5-1213 to provide access to the bound property's
generic type information (eg ListSomeBean). Basically the generic type
information needs to be passed from PropertyConduitSource to
ComponentResources

This change requires adding a generic type getter to a few public
interfaces, namely:
- org.apache.tapestry5.Binding
- org.apache.tapestry5.ComponentResources
- org.apache.tapestry5.PropertyConduit
- org.apache.tapestry5.ioc.services.PropertyAdapter

I realise that adding methods to public interfaces breaks backwards
compatability. What's people's thoughts on this?

Re: Wrong default types for validate/translate in AbstractTextField?

[Lance Java]

Hi Michael, in future... Please post to the user's mailing list. This list
is for the tapestry development team.

No, this is not a bug. Pages and components are singletons. Under the hood
they use bindings to get() and set() dynamic values at runtime. In this
instance the binding can get() a FieldTranslate instance at runtime.

You are probably more familiar with the prop: binding which can access a
property at runtime.
 On 16 May 2014 18:02, Michael Wyraz michael.wy...@evermind.de wrote:

 Hi,

 I found something I do not understand and which is probably a bug. From
 org.apache.tapestry5.corelib.base.AbstractTextField:

 @Parameter(required = true, allowNull = false, defaultPrefix =
 BindingConstants.TRANSLATE)
 private FieldTranslatorObject translate;

 @Parameter(defaultPrefix = BindingConstants.VALIDATE)
 @SuppressWarnings(unchecked)
 private FieldValidatorObject validate;

 But the type of the default() methods differ:

 final Binding defaultTranslate()
 {
 return defaultProvider.defaultTranslatorBinding(value,
 resources);
 }

 final Binding defaultValidate()
 {
 return defaultProvider.defaultValidatorBinding(value,
 resources);
 }

 The interfaces Binding and FieldTranslator have nothing common. So I
 cannot imagine that (and how) this could work.

 Is it a bug?

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

Re: TAP5-1213: Changes to public API

[Lance Java]

I've managed to solve the issue without affecting org.apache.tapestry5.ioc.
services.PropertyAdapter.

So the introduced methods are:
Type Binding.getBindingGenericType()
Type PropertyConduit getPropertyGenericType()
Type ComponentResources.getBoundGenericType(String parameterName)

I don't think anyone will be implementing their own ComponentResources or
PropertyConduit so I think those changes are fin. Ashas been mentioned,
third parties (including myself) have implemented custom bindings. If it's
any consolation, I've implemented AbstractBinding.getBindingGenericType()
to simply return getBindingType().

The other solution I can see is to have Binding2 in a similar style to
Asset2 etc.


On 16 May 2014 00:48, Howard Lewis Ship hls...@gmail.com wrote:

 I'd need to know a bit more; this will tend to break 3rd party libraries
 that compile against the old code, which is not so good. Possibly if the
 new information could be added under an entirely new method of the existing
 APIs that would be less of a problem.


 On Wed, May 14, 2014 at 1:33 PM, Lance Java lance.j...@googlemail.com
 wrote:

  I'm looking into TAP5-1213 to provide access to the bound property's
  generic type information (eg ListSomeBean). Basically the generic type
  information needs to be passed from PropertyConduitSource to
  ComponentResources
 
  This change requires adding a generic type getter to a few public
  interfaces, namely:
  - org.apache.tapestry5.Binding
  - org.apache.tapestry5.ComponentResources
  - org.apache.tapestry5.PropertyConduit
  - org.apache.tapestry5.ioc.services.PropertyAdapter
 
  I realise that adding methods to public interfaces breaks backwards
  compatability. What's people's thoughts on this?
 



 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com
 @hlship

Re: TAP5-1213: Changes to public API

[Lance Java]

So, is it OK to commit the changes? It will obviously need a breaking
change note in the release notes.
 On 18 May 2014 00:10, Howard Lewis Ship hls...@gmail.com wrote:

 It can be problematic; I don't expect people to implement
 ComponentResources ... but some other common interfaces, such as
 FormSupport, are often proxied/delegated in a way that provides pain when
 new methods are added.  JDK 8 default methods may help there, hard to say
 so far.


 On Sat, May 17, 2014 at 1:27 PM, Lance Java lance.j...@googlemail.com
 wrote:

  I've managed to solve the issue without affecting
 org.apache.tapestry5.ioc.
  services.PropertyAdapter.
 
  So the introduced methods are:
  Type Binding.getBindingGenericType()
  Type PropertyConduit getPropertyGenericType()
  Type ComponentResources.getBoundGenericType(String parameterName)
 
  I don't think anyone will be implementing their own ComponentResources or
  PropertyConduit so I think those changes are fin. Ashas been mentioned,
  third parties (including myself) have implemented custom bindings. If
 it's
  any consolation, I've implemented AbstractBinding.getBindingGenericType()
  to simply return getBindingType().
 
  The other solution I can see is to have Binding2 in a similar style to
  Asset2 etc.
 
 
  On 16 May 2014 00:48, Howard Lewis Ship hls...@gmail.com wrote:
 
   I'd need to know a bit more; this will tend to break 3rd party
 libraries
   that compile against the old code, which is not so good. Possibly if
 the
   new information could be added under an entirely new method of the
  existing
   APIs that would be less of a problem.
  
  
   On Wed, May 14, 2014 at 1:33 PM, Lance Java lance.j...@googlemail.com
   wrote:
  
I'm looking into TAP5-1213 to provide access to the bound property's
generic type information (eg ListSomeBean). Basically the generic
  type
information needs to be passed from PropertyConduitSource to
ComponentResources
   
This change requires adding a generic type getter to a few public
interfaces, namely:
- org.apache.tapestry5.Binding
- org.apache.tapestry5.ComponentResources
- org.apache.tapestry5.PropertyConduit
- org.apache.tapestry5.ioc.services.PropertyAdapter
   
I realise that adding methods to public interfaces breaks backwards
compatability. What's people's thoughts on this?
   
  
  
  
   --
   Howard M. Lewis Ship
  
   Creator of Apache Tapestry
  
   The source for Tapestry training, mentoring and support. Contact me to
   learn how I can get you up and productive in Tapestry fast!
  
   (971) 678-5210
   http://howardlewisship.com
   @hlship
  
 



 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com
 @hlship

Re: TAP5-1213: Changes to public API

[Lance Java]

I've uploaded the patch to jira
https://issues.apache.org/jira/browse/TAP5-1213
https://issues.apache.org/jira/secure/attachment/12645469/TAP5-1213.patch

Cheers,
Lance.


On 18 May 2014 16:49, Ulrich Stärk u...@spielviel.de wrote:

 If you are unsure you can send the patch here and ask for reviews.

 Uli

 On 2014-05-18 16:39, Lance Java wrote:
  So, is it OK to commit the changes? It will obviously need a breaking
  change note in the release notes.
   On 18 May 2014 00:10, Howard Lewis Ship hls...@gmail.com wrote:
 
  It can be problematic; I don't expect people to implement
  ComponentResources ... but some other common interfaces, such as
  FormSupport, are often proxied/delegated in a way that provides pain
 when
  new methods are added.  JDK 8 default methods may help there, hard to
 say
  so far.
 
 
  On Sat, May 17, 2014 at 1:27 PM, Lance Java lance.j...@googlemail.com
  wrote:
 
  I've managed to solve the issue without affecting
  org.apache.tapestry5.ioc.
  services.PropertyAdapter.
 
  So the introduced methods are:
  Type Binding.getBindingGenericType()
  Type PropertyConduit getPropertyGenericType()
  Type ComponentResources.getBoundGenericType(String parameterName)
 
  I don't think anyone will be implementing their own ComponentResources
 or
  PropertyConduit so I think those changes are fin. Ashas been mentioned,
  third parties (including myself) have implemented custom bindings. If
  it's
  any consolation, I've implemented
 AbstractBinding.getBindingGenericType()
  to simply return getBindingType().
 
  The other solution I can see is to have Binding2 in a similar style to
  Asset2 etc.
 
 
  On 16 May 2014 00:48, Howard Lewis Ship hls...@gmail.com wrote:
 
  I'd need to know a bit more; this will tend to break 3rd party
  libraries
  that compile against the old code, which is not so good. Possibly if
  the
  new information could be added under an entirely new method of the
  existing
  APIs that would be less of a problem.
 
 
  On Wed, May 14, 2014 at 1:33 PM, Lance Java 
 lance.j...@googlemail.com
  wrote:
 
  I'm looking into TAP5-1213 to provide access to the bound property's
  generic type information (eg ListSomeBean). Basically the generic
  type
  information needs to be passed from PropertyConduitSource to
  ComponentResources
 
  This change requires adding a generic type getter to a few public
  interfaces, namely:
  - org.apache.tapestry5.Binding
  - org.apache.tapestry5.ComponentResources
  - org.apache.tapestry5.PropertyConduit
  - org.apache.tapestry5.ioc.services.PropertyAdapter
 
  I realise that adding methods to public interfaces breaks backwards
  compatability. What's people's thoughts on this?
 
 
 
 
  --
  Howard M. Lewis Ship
 
  Creator of Apache Tapestry
 
  The source for Tapestry training, mentoring and support. Contact me to
  learn how I can get you up and productive in Tapestry fast!
 
  (971) 678-5210
  http://howardlewisship.com
  @hlship
 
 
 
 
 
  --
  Howard M. Lewis Ship
 
  Creator of Apache Tapestry
 
  The source for Tapestry training, mentoring and support. Contact me to
  learn how I can get you up and productive in Tapestry fast!
 
  (971) 678-5210
  http://howardlewisship.com
  @hlship
 
 

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

Re: [VOTE] Drop support for Java 5 in Tapestry 5.4 (2nd attempt)

[Lance Java]

Lance Semmens +0 (non-binding)

I can't really see much benefit but I won't stand in the way.
 On 18 May 2014 18:05, Jochen Kemnade kemn...@gmail.com wrote:

 There have been discussions whether we want to keep compatibility with
 Java 5 for the upcoming 5.4 release.
 Java 5 is EOSL since October 2009.
 While requiring Java 6 would not bring us much benefits, there might be
 some libraries that we cannot use because they do not support Java 5.
 Also, we'd spare ourselves some efforts not having to support Java 5
 anymore.
 The vote will run for 3 days and, if it succeeds, I will increase the
 minimum required Java version to 1.6.

 Jochen Kemnade: +1 (non-binding)

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

Re: TAP5-1213: Changes to public API

[Lance Java]

I guess my question is, is it worth adding / maintaining Binding2 and
PropertyConduit2 and all the type checking / adapting.

Or are we happy to add the methods to the public API given its a no brainer
to implement getGenericType() to return getType()
 On 19 May 2014 15:17, Thiago H de Paula Figueiredo thiag...@gmail.com
wrote:

 On Sat, 17 May 2014 14:27:21 -0300, Lance Java lance.j...@googlemail.com
 wrote:

  I don't think anyone will be implementing their own ComponentResources or
 PropertyConduit so I think those changes are fin.


 Agreed with ComponentResources, not about PropertyConduit, but I still
 think that wouldn't be a problem, specially if a new PropertyConduit2
 interface is defined.

 --
 Thiago H. de Paula Figueiredo
 Tapestry, Java and Hibernate consultant and developer
 http://machina.com.br

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

Re: TAP5-1213: Changes to public API

[Lance Java]

I can implement like that if others agree. I just hate instanceof littered
around the place.

It also brings up the possibility of third parties wrapping a Binding2 with
a Binding and losing functionality. I'd prefer a compilation error myself.
 On 19 May 2014 17:46, Thiago H de Paula Figueiredo thiag...@gmail.com
wrote:

 On Mon, 19 May 2014 13:04:55 -0300, Lance Java lance.j...@googlemail.com
 wrote:

  I guess my question is, is it worth adding / maintaining Binding2 and
 PropertyConduit2 and all the type checking / adapting.

 Or are we happy to add the methods to the public API given its a no
 brainer to implement getGenericType() to return getType()


 Considering we've dealt with this kind of scenario using the first option
 (Binding2 and PropertyConduit2), I'd go with it. I guess just a handful of
 places would need to be adapted.

 --
 Thiago H. de Paula Figueiredo
 Tapestry, Java and Hibernate consultant and developer
 http://machina.com.br

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

Re: TAP5-1213: Changes to public API

[Lance Java]

ok, just committed with Binding2 / PropertyConduit2 keeping backwards
compatibility in tact.


On 19 May 2014 19:02, Lance Java lance.j...@googlemail.com wrote:

 I can implement like that if others agree. I just hate instanceof littered
 around the place.

 It also brings up the possibility of third parties wrapping a Binding2
 with a Binding and losing functionality. I'd prefer a compilation error
 myself.
  On 19 May 2014 17:46, Thiago H de Paula Figueiredo thiag...@gmail.com
 wrote:

 On Mon, 19 May 2014 13:04:55 -0300, Lance Java lance.j...@googlemail.com
 wrote:

  I guess my question is, is it worth adding / maintaining Binding2 and
 PropertyConduit2 and all the type checking / adapting.

 Or are we happy to add the methods to the public API given its a no
 brainer to implement getGenericType() to return getType()


 Considering we've dealt with this kind of scenario using the first option
 (Binding2 and PropertyConduit2), I'd go with it. I guess just a handful of
 places would need to be adapted.

 --
 Thiago H. de Paula Figueiredo
 Tapestry, Java and Hibernate consultant and developer
 http://machina.com.br

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

Re: TAP5-1213: Changes to public API

[Lance Java]

I agree but thought I was in the minority.

The extra interfaces have increased the complexity and require third
parties to know about the nuances of the implementation. Adding methods to
the public API may cause compilation errors (in rare cases) but at least
it's clear.

Anyone else have an opinion?
 On 20 May 2014 00:13, Kalle Korhonen kalle.o.korho...@gmail.com wrote:

 JMHO, maintaining backwards compatibility in this case isn't worth the
 added complexity. Making support libraries compatible requires just
 compiling them against the new version and there are many other, more
 drastic changes in 5.4 that require at least a re-compilation and in many
 cases, changes in the library code. Just my point of view as an author of
 multiple T5.4 support libraries.

 Kalle


 On Mon, May 19, 2014 at 1:52 PM, Lance Java lance.j...@googlemail.com
 wrote:

  ok, just committed with Binding2 / PropertyConduit2 keeping backwards
  compatibility in tact.
 
 
  On 19 May 2014 19:02, Lance Java lance.j...@googlemail.com wrote:
 
   I can implement like that if others agree. I just hate instanceof
  littered
   around the place.
  
   It also brings up the possibility of third parties wrapping a Binding2
   with a Binding and losing functionality. I'd prefer a compilation error
   myself.
On 19 May 2014 17:46, Thiago H de Paula Figueiredo 
  thiag...@gmail.com
   wrote:
  
   On Mon, 19 May 2014 13:04:55 -0300, Lance Java 
  lance.j...@googlemail.com
   wrote:
  
I guess my question is, is it worth adding / maintaining Binding2 and
   PropertyConduit2 and all the type checking / adapting.
  
   Or are we happy to add the methods to the public API given its a no
   brainer to implement getGenericType() to return getType()
  
  
   Considering we've dealt with this kind of scenario using the first
  option
   (Binding2 and PropertyConduit2), I'd go with it. I guess just a
 handful
  of
   places would need to be adapted.
  
   --
   Thiago H. de Paula Figueiredo
   Tapestry, Java and Hibernate consultant and developer
   http://machina.com.br
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
   For additional commands, e-mail: dev-h...@tapestry.apache.org
  
  
 

Re: tapestry-ioc java 8

[Lance Java]

Tapestry has switched to plastic for its byte code magic. Currently,
plastic isn't well documented. I find that the best documentation currently
is the test cases. Perhaps you can find your answer here:

https://github.com/apache/tapestry-5/tree/master/plastic/src/test/groovy/org/apache/tapestry5/plastic
 On 19 May 2014 23:46, Jigar Joshi jiga...@gmail.com wrote:

 Hello

 ​with tapestry 5.3.4 and java 7 with use of
 org.apache.tapestry5.ioc.services.ClassFactory



 private Class? createProxyClass(ServiceResources resources) {
 Class? serviceInterface = resources.getServiceInterface();

 ClassFab cf = classFactory.newClass(serviceInterface);

 // add field
 cf.addField(_creator, Modifier.PRIVATE | Modifier.FINAL,
 SomeClass.class);

 // Constructor takes a ServiceCreator
 cf.addConstructor(new Class[] { SomeClass.class }, null, _creator
 = $1;);

 // add method
 String body = format(return (%s) _creator.get();,
 serviceInterface.getName());
 MethodSignature sig = new MethodSignature(serviceInterface,
 SCOPE_METHOD_NAME, null, null);
 cf.addMethod(Modifier.PRIVATE, sig, body);
 String toString = format(Scoped Proxy for scope(%s): %s(%s),
 scope, resources.getServiceId(),
 serviceInterface.getName());

 cf.proxyMethodsToDelegate(serviceInterface, SCOPE_METHOD_NAME +
 (), toString);

 return cf.createClass();
 }





 with tapestry 5.4-beta3 this class has been removed (it was depricated)

 I played around a little bit to find related implementation in new replaced
 class

 org.apache.tapestry5.ioc.services.PlasticProxyFactory

 couldn't find it offhand, how to achieve same thing with tapestry 5.4 ?

 Thanks!
 Jigar

Re: TAP5-1213: Changes to public API

[Lance Java]

 wouldn't adding methods to the existing interfaces lead to libraries
written for (and compiled against) Tapestry 5.3 would not work with
Tapestry 5.4 anymore?

In this instance, I would assume an AbstractMethodError would be thrown
when calling the new method:
ComponentResources.getBoundGenericType(paramName)

This would only occur in third party bindings / propertyConduits that don't
extend core (internal) implementations.

IMHO these exceptions are likely to be rare as hen's teeth ;)

Re: TAP5-1213: Changes to public API

[Lance Java]

I was referring to the exception being rare, not third party
implementations.

Keep in mind that the exception will only occur when invoking the new
method on ComponentResources. At the moment there is no such code in
existence.
 On 20 May 2014 13:51, Thiago H de Paula Figueiredo thiag...@gmail.com
wrote:

 On Tue, 20 May 2014 07:20:21 -0300, Lance Java lance.j...@googlemail.com
 wrote:

  This would only occur in third party bindings / propertyConduits that
 don't extend core (internal) implementations.

 IMHO these exceptions are likely to be rare as hen's teeth ;)


 Agreed for ComponentResources, less agreed for Binding and disagreed for
 PropertyConduit, which is used inside some projects to implement some
 properties for BeanModel-based components. This is *not* uncommon to be
 found in non-library code.

 --
 Thiago H. de Paula Figueiredo
 Tapestry, Java and Hibernate consultant and developer
 http://machina.com.br

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

Re: TAP5-1213: Changes to public API

[Lance Java]

Haha... I could try / catch AbstractMethodError and get rid of Binding2 /
PropertyConduit2. Win!

Jokes...
 On 20 May 2014 17:46, Jochen Kemnade kemn...@gmail.com wrote:

 True, but if they occur, the cause is not so easy to find IMO.

Re: Abandon java.beans.Introspector or keep working around it?

[Lance Java]

Yeah, I must say I thinking the same thing. It's not rocket science what
the introspector is doing. We could support isX() for java.lang.Boolean too
if we had our own introspector.
 On 28 Jun 2014 13:54, Thiago H de Paula Figueiredo thiag...@gmail.com
wrote:

 Hi!

 While investigating TAP5-1548 and TAP5-1885 and also reading TAP5-921 I
 reached the conclusion that Introspector isn't finding all the properties
 in some circustances, specially when the getter is defined in one type and
 the setter in another one in the class hierarchy. The tickets have
 examples. What do you guys think about ditching its use? Or do you think we
 should work around it?

 Meanwhile, I'm trying a workaround.

 Cheers!

 --
 Thiago H. de Paula Figueiredo
 Tapestry, Java and Hibernate consultant and developer
 http://machina.com.br

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

Rename tapestry-ioc to hivemind

[Lance Java]

I asked this question before I was a committer and generally got good
feedback but it never really went anywhere.

I think having tapestry-ioc and tapestry (the web framework) is a bit
confusing. I also feel that it hinders the promotion / adoption of
tapestry-ioc as a standalone product.

So, I have some questions to consider.
1. Do you agree that tapestry-ioc should be renamed?
2. Do you think it should be called hivemind?
3. Do you have an alternative name?
4. Should a rename be done as part of 5.4 or 5.5?

If the feedback to this thread forms a general consensus, I'll put it to a
proper vote.

Lance.

Re: Rename tapestry-ioc to hivemind

[Lance Java]

Hi Dimitris, I'm not (at this stage) suggesting to move tapestry-ioc
outside of the tapestry build / release. I'm just suggesting a rename at
the moment and it can live inside the tapestry build, similar to plastic.
 On 19 Jul 2014 09:11, Dimitris Zenios dimitris.zen...@gmail.com wrote:

 I use tapestry-ioc in many projects outside of tapestry web framework.

 I agree that it should be taken out of the tapestry-web and form its own
 project.


 On Sat, Jul 19, 2014 at 11:02 AM, Lance Java lance.j...@googlemail.com
 wrote:

  I asked this question before I was a committer and generally got good
  feedback but it never really went anywhere.
 
  I think having tapestry-ioc and tapestry (the web framework) is a bit
  confusing. I also feel that it hinders the promotion / adoption of
  tapestry-ioc as a standalone product.
 
  So, I have some questions to consider.
  1. Do you agree that tapestry-ioc should be renamed?
  2. Do you think it should be called hivemind?
  3. Do you have an alternative name?
  4. Should a rename be done as part of 5.4 or 5.5?
 
  If the feedback to this thread forms a general consensus, I'll put it to
 a
  proper vote.
 
  Lance.
 

Re: Rename tapestry-ioc to hivemind

[Lance Java]

As discussed, I'm not suggesting to move the project outside of the
tapestry build / release. I'm also not tied to the hivemind name.

I constantly find myself saying tapestry (the web framework) and
tapestry-ioc on the user's list. A rename would help remove this ambiguity.
On 21 Jul 2014 11:42, Bob Harner bobhar...@gmail.com wrote:

 I don't think it's a good idea to resurrect old software product names,
 because you bring with them all the old connotations. To the extent people
 know about Hivemind, they think of the product as old, out of date  dead.

 Also, there were good reasons why Tapestry-IOC was not treated as a
 distinct project. As our docs say: The difficulty of managing the release
 schedules of two complex frameworks proved to be an issue.
 On Jul 21, 2014 3:22 AM, Jochen Kemnade jochen.kemn...@eddyson.de
 wrote:

  Hi,
 
  Am 19.07.2014 10:02, schrieb Lance Java:
 
  I think having tapestry-ioc and tapestry (the web framework) is a bit
  confusing. I also feel that it hinders the promotion / adoption of
  tapestry-ioc as a standalone product.
 
 
  I see your point. I don't really have a strong opinion about that matter,
  but here we go.
 
   1. Do you agree that tapestry-ioc should be renamed?
 
 
  No. That's in terms of should, not could. I'm not against a rename, I
  just don't think it's necessary.
 
   2. Do you think it should be called hivemind?
 
 
  No. I also think that the name hivemind is taken and we shouldn't
  resurrect it. People would probably start to dig out old documentation
 and
  mailing list threads.
 
   3. Do you have an alternative name?
 
 
  What about something with a relation to the word tapestry? Something
  like cotton, cloth, fabric (hm, I like that one, but there's at least
  http://www.fabfile.org/ and http://dev.mysql.com/downloads/fabric/).
 
   4. Should a rename be done as part of 5.4 or 5.5?
 
 
  I assume that's an XOR. ;-) I guess it depends on how thorough we want
 the
  change to be. Do we also want to rename all the packages and classes with
  IOC in them? Then we'd probably even have to wait for 6.0. If it's just
  the name and the documentation, I think we could do it for 5.4.
 
  Jochen
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
  For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 

Re: Rename tapestry-ioc to hivemind

[Lance Java]

How's about tapioca as a name suggestion? It has references to tapestry and
ioc. :)
On 21 Jul 2014 14:38, Thiago H de Paula Figueiredo thiag...@gmail.com
wrote:

 On Sat, 19 Jul 2014 05:02:28 -0300, Lance Java lance.j...@googlemail.com
 wrote:

  I asked this question before I was a committer and generally got good
 feedback but it never really went anywhere.

 I think having tapestry-ioc and tapestry (the web framework) is a bit
 confusing. I also feel that it hinders the promotion / adoption of
 tapestry-ioc as a standalone product.


 I'm not sure what to think about this. Mixed feelings. I've posted before
 that it would have been better for Tapestry-IoC for it to not have
 'Tapestry' in its name and Howard agreed. But, now, I'm not sure a rename
 would do more harm or good. Tapestry 5, both web framework and IoC, had its
 first final release in April 12, 2009, five years ago. There's already lots
 of documentation and blog posts and etc about it, so a rename for avoiding
 confusion would end up causing more confusion of its own.

 I agree with Bob about not ressurecting old product names. It would add
 more confusion. HiveMind was XML-heavy, and Tapestry-IoC is XML-free. Maybe
 Tapestry 5 itself shouldn't have been named Tapestry, for the same reason,
 as it was a rewrite for scratch.

 Regarding the development cycle, I don't think right now it's a speed bump
 for Tapestry-IoC. As an IoC core (kernel?), it's a mature product. Its last
 major change I could remember was the copying of service implementation
 annotations to the corresponding service proxies. Before that, live class
 reloading for service implementations and JSR 303's @Inject support. I
 guess the features Tapestry-IoC would most benefit from now on don't need
 changes in itself, but additional packages that integrate it with other
 stuff. Of course, other people may see things differently, and I love to
 discuss it.

 Summary: I wish Tapestry-IoC had another name and that it wasn't HiveMind
 (maybe Collective?), but IMHO it's too late to rename it, even if I think
 discussing it is a very good thing.

 --
 Thiago H. de Paula Figueiredo
 Tapestry, Java and Hibernate consultant and developer
 http://machina.com.br

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

Re: Rename tapestry-ioc to hivemind

[Lance Java]

Ok, I'll have to admit defeat and let the ambiguity continue...

;)
 On 21 Jul 2014 17:08, Howard Lewis Ship hls...@gmail.com wrote:

 I think Thiago's summary ... that tapestry-ioc is five years old, so
 renaming it will cause more confusion than good, is right on the money.  I
 would not support a rename.


 On Mon, Jul 21, 2014 at 6:51 AM, Thiago H de Paula Figueiredo 
 thiag...@gmail.com wrote:

  On Mon, 21 Jul 2014 10:46:00 -0300, Lance Java 
 lance.j...@googlemail.com
  wrote:
 
   How's about tapioca as a name suggestion? It has references to tapestry
  and ioc. :)
 
 
  That's making me hungry and it's not lunch time here yet! :D
 
  A quick Google search for tapioca framework shows a number of existing
  stuff with that name, though, even a Java IoC framework:
  http://code.google.com/p/tapioca/.
 
 
  --
  Thiago H. de Paula Figueiredo
  Tapestry, Java and Hibernate consultant and developer
  http://machina.com.br
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
  For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 


 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com
 @hlship

Re: [VOTE] Apache Tapestry 5.4-beta-17

[Lance Java]

Lance S: +1 (non-binding)
 On 2 Sep 2014 20:19, Howard Lewis Ship hls...@gmail.com wrote:

 I've created and uploaded a release of Tapestry 5.4-beta-17, ready to be
 voted upon.

 The source and source downloads are uploaded to:

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

 and the Maven artifacts staged to:

 https://repository.apache.org/content/repositories/staging/

 Please examine these files to determine if the new release, 5.4-beta-17, is
 ready.

 I've also created a 5.4-beta-17 tag in Git:


 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=90e9bccb2cd3ebc8b502bee0bfc2aa03d11d9ba7

 Vote will run for three days; On a successful vote, I'll release the Maven
 artifacts, and move the source and javadoc distributions from these
 directories
 to the proper distribution directories and update the Tapestry site
 documentation, and send out appropriate notifications.


 Howard M. Lewis Ship: +1 (binding)



 P.S. This is the current release notes from JIRA:


 Release Notes - Tapestry 5 - Version 5.4




 ** Bug
 * [TAP5-311] - NPE in BeanDisplay if used in a form with a default
 model
 * [TAP5-736] - TextField validate parameter allows Null, but throws NPE
 * [TAP5-773] - Select component should have parameter to allow option
 labels to be rendered w/o HTML entity escaping
 * [TAP5-800] - Server side error during provideCompletions event for
 Autocompleter mixin is not reported on the client side properly
 * [TAP5-805] - DateField does not allow disabling of client-side
 validation, side-effects
 * [TAP5-860] - JavaScript errors when adding validations to checkboxes
 * [TAP5-901] - Generics return wrong type when subclassing page
 * [TAP5-983] - CLONE -NPE in BeanDisplay if used in a form with a
 default model
 * [TAP5-986] - A request can fail with an NPE in some cases, when a
 Tapestry page is acting as the servlet container error page
 * [TAP5-1010] - Fix Finnish validation message translation - corrected
 file attached
 * [TAP5-1066] - Client-Id and Links in Grid not correct when putting a
 Grid inside a Loop
 * [TAP5-1193] - tapestry.js prevents using the back/forward browser
 cache
 * [TAP5-1200] - Nested Ajax calls result in a call to $T(null)
 * [TAP5-1305] - Service decorations can fail if using the conventional
 naming
 * [TAP5-1480] - Couldn't create property conduits for generic
 interfaces
 * [TAP5-1493] - Property expressions on properties that are covariant
 on a base class use the type of the base class property, not the covariant
 subclass
 * [TAP5-1548] - Property expressions fails when using a supertype that
 implements an interface with a matching method
 * [TAP5-1569] - Grid should implement the ClientElement interface
 * [TAP5-1601] - Sometime a method that references a field with a
 conduit will not be instrumented, resulting in an NPE accessing the field
 itself
 * [TAP5-1658] - Submit context does not work inside Grid
 * [TAP5-1668] - JavaDoc for @Parameter.value() should be clearer about
 the empty string
 * [TAP5-1672] - PropertyDisplay component will swallow NPEs when
 evaluating the property, leaving no clue about the actual NPE
 * [TAP5-1689] - Grid pagination details should be overridable via a
 Grid parameter to support Grids that render in loops
 * [TAP5-1691] - AssetPathConstructorImpl should URL-encode the
 application version
 * [TAP5-1704] - Localizing the Today and None labels in the core
 datefield component
 * [TAP5-1729] - Sometimes YUICompressor can fail with
 java.util.EmptyStackException
 * [TAP5-1730] - Ajax Zone is improperly reloaded when a mixin submits
 form via JavaScript
 * [TAP5-1734] - Race condition loading JavaScript libraries with
 ProgressiveDisplay
 * [TAP5-1735] - Most packages lack package-level javadocs
 * [TAP5-1736] - Overriding a base class abstract event handler method
 causes the sub-class method to be invoked twice
 * [TAP5-1741] - Parsing template which contains Chinese (Maybe other
 double bytes) words throws MalformedByteSequenceException: Invalid byte 3
 of 3-byte UTF-8 sequence.
 * [TAP5-1742] - AfterRender() in Loop component should not short
 circuit
 * [TAP5-1744] - Returning a StreamPageContent instance from any of a
 Form's events results in Form components may not be placed inside other
 Form components exception
 * [TAP5-1752] - Component cannot receive any event in a case when
 transformer added event handler before OnEventWorker
 * [TAP5-1762] - Some components do not have include a description of
 their parameters in their JavaDoc pages
 * [TAP5-1765] - PerThread scope is not honored when service is created
 using autobuild
 * [TAP5-1768] - @ActivationRequestParameter does not encode to be URL
 friendly
 * [TAP5-1769] - Form submitted with an ajax request should not have the
 ValidationTracker persist values
 * [TAP5-1770] - PageTester 

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

[Lance Java]

Lance S. +1 (non-binding)
On 12 Sep 2014 23:36, Howard Lewis Ship hls...@gmail.com wrote:

 The perfect is the enemy of the good. It's been too long since the last
 beta ... and I'd love to get a GA out this year. I had originally hoped for
 last December!

 On Fri, Sep 12, 2014 at 10:54 AM, Jochen Kemnade kemn...@gmail.com
 wrote:

  Yes, you're right, we can do another beta every time we like, I just
 have a
  slightly bad feeling about releasing a *public* beta that we know has a
 bug
  that we already have a fix for. But I agree, it's nothing that
 necessarily
  has to prevent a release, that's why I voted +0.
 



 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com
 @hlship

Re: REVOTE: Apache Tapestry 5.4-beta-22

[Lance Java]

Lance S: +1 (non-binding)
 On 2 Oct 2014 15:26, Howard Lewis Ship hls...@gmail.com wrote:

Since the last vote was actually a fail (not enough binding +1 votes),
let's do a re-vote to make it official that beta-22 is properly endorsed as
a beta release by the Tapestry PMC.

Howard M. Lewis Ship: +1 (binding)

--
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com
@hlship

Re: BeanModel classes as a separate project and/or JAR?

[Lance Java]

Sounds useful. I'm assuming plastic would need to be on the classpath but
tapestry-ioc would not?

Re: BeanModel classes as a separate project and/or JAR?

[Lance Java]

For a BeanModel framework to come packaged with tapestry-ioc feels like
bloatware to me.

Re: BeanModel classes as a separate project and/or JAR?

[Lance Java]

Yes... It would be a dependency rather than the same package. Either way
it's the same net result (tapestry-ioc on the classpath when all you wanted
was a bean mapper). That's the bloatware I was speaking of.
 On 9 Oct 2014 22:19, Thiago H de Paula Figueiredo thiag...@gmail.com
wrote:

 On Thu, 09 Oct 2014 10:42:48 -0300, Lance Java lance.j...@googlemail.com
 wrote:

  For a BeanModel framework to come packaged with tapestry-ioc feels like
 bloatware to me.


 I suggested a BeanModel JAR with a dependency on Tapestry-IoC, not
 including Tapestry-IoC, in case we cannot really make a standalone
 BeanModel JAR.

 --
 Thiago H. de Paula Figueiredo
 Tapestry, Java and Hibernate consultant and developer
 http://machina.com.br

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

Re: [VOTE] Tapestry Release 5.3.8

[Lance Java]

Lance S: +1 (non-binding)
 On 20 Nov 2014 19:21, Kalle Korhonen kalle.o.korho...@gmail.com wrote:

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

 The source and source downloads are uploaded to:
 http://people.apache.org/~kaosko/tapestry-releases/

 and the Maven artifacts staged to:

 https://repository.apache.org/content/repositories/orgapachetapestry-1035

 Please examine these files to determine if the new release, 5.3.8, is
 ready.

 I've also created a 5.3.8 tag in Git:


 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=shortlog;h=refs/tags/
 5.3.8

 Release notes page has been updated too.

 Vote will run for three days; On a successful vote, I'll release the Maven
 artifacts, and move the source and javadoc distributions from these
 directories
 to the proper distribution directories and update the Tapestry site
 documentation, and send out appropriate notifications.


 Kalle Korhonen: +1 (non-binding)

Re: BeanModel and Commons package

[Lance Java]

Educated stab in the dark here but does ClasspathScannerImpl assume each
package is contained within a single jar?

I'm guessing Thiago's changes involved splitting a single package across 2
(maybe 3) jars to maintain backwards compatibility.
On 23 Dec 2014 23:00, Howard Lewis Ship hls...@gmail.com wrote:

 I'm doing a build of latest, currently.  Seeing one oddity:

 ioc.specs.ClasspathScannerImplSpec  can locate classes inside a
 subpackage, inside an extracted JAR file FAILED
 org.spockframework.runtime.ConditionNotSatisfiedError at
 ClasspathScannerImplSpec.groovy:40

 708 tests completed, 1 failed, 2 skipped
 :tapestry-ioc:test FAILED

 Off to investigate.

 On Mon, Dec 22, 2014 at 5:12 AM, Jochen Kemnade kemn...@gmail.com wrote:

  I have to admit that I didn't have a chance to look into the changes you
  made yet, and probably, I won't get to doing that until 2015.
  But a new beta would be a good way to make more people (including me)
 give
  them a try in the near future, so I'd say, just go ahead. :-)
 



 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com
 @hlship

Re: VOTE: Jochen Kemnade as PMC member

[Lance Java]

Lance S +1 (non-binding)
On 27 Feb 2015 00:38, Howard Lewis Ship hls...@gmail.com wrote:

 If you haven't been noticing, Jochen has been putting in a lot of time on
 Tapestry; closing bugs, leading discussions, and mentoring people on the
 mailing list. He's been at it a more than long enough to show real
 commitment ... I'd love to see someone this charged up added to the
 Tapestry PMC.

 This is a binding vote to run for three days. It requires majority
 approval: at least three binding +1's and more binding +1's than -1's.

 Howard M. Lewis Ship: +1 (binding)

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com
 @hlship

Re: What if … just jQuery?

[Lance Java]

I'm ok with using jquery directly, it would be interesting to know if
anyone is actually using 5.4 + prototype (I doubt it). The good thing about
jquery, compared to prototype, is that it doesn't pollute existing
javascript objects (eg string). jquery is 35kb minified/gzipped, if people
want to use a different 'foundation' framework than jquery, I doubt the
extra 35kb is a deal breaker to have both in use.

Re: [VOTE] Switch to release candidate

[Lance Java]

Lance S
+1 (non-binding)

Re: Update ASM before 5.4 final?

[Lance Java]

Apart from repackaging... Is there anything special we do with ASM?

Perhaps we could automate this using jarjar or shadow gradle plugins?
On 12 Aug 2015 11:34, Jochen Kemnade jochen.kemn...@eddyson.de wrote:

 Hi,

 currently, we ship ASM 5.0.1 with plastic, the latest version is 5.0.4:
 http://asm.ow2.org/history.html. As the 5.4 release seems to be coming
 close (yeah!), I'd like to get that up-to-date.
 What's the current way to update the sources? Is it a completely manual
 process, as in download the tgz, extract the relevant part from the archive
 and sed the package statement?

 Jochen

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

Re: [VOTE] 5.4-beta-35

[Lance Java]

Lance S: +1 (non-binding)
On 19 Aug 2015 00:42, Kalle Korhonen kalle.o.korho...@gmail.com wrote:

 Kalle Korhonen: +1 (non-binding)

 On Tue, Aug 18, 2015 at 2:12 PM, françois facon fra.fa...@gmail.com
 wrote:

  François Facon: +1 (non binding)
 
  2015-08-18 20:44 GMT+02:00 Dimitris Zenios dimitris.zen...@gmail.com:
 
   +1 (non binding)
  
   On Tue, Aug 18, 2015 at 9:23 PM, Howard Lewis Ship hls...@gmail.com
   wrote:
  
Howard M. Lewis Ship: +1 (binding)
   
On Tue, Aug 18, 2015 at 10:32 AM, Andreas Ernst a...@ae-online.de
  wrote:
   
 Andreas Ernst: +1 (non-binding)

 Am 18.08.15 um 18:33 schrieb Jochen Kemnade:

 Hi,

 I've created and uploaded a release of Tapestry 5.4-beta-35, ready
  to
   be
 voted upon.

 The source and binary downloads are uploaded to:

 https://dist.apache.org/repos/dist/dev/tapestry

 and the Maven artifacts staged to:

 https://repository.apache.org/content/repositories/staging

 Please examine these files to determine if the new release,
   5.4-beta-35,
 is ready.

 I've also created a 5.4-beta-35 tag in Git:



   
  
 
 https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.4-beta-35

 Vote will run for three days at least; On a successful vote, I'll
 release the Maven artifacts, and move the source and javadoc
 distributions from these directories to the proper distribution
 directories and update the Tapestry site documentation, and send
 out
 appropriate notifications.

 Jochen



 --
 ae | Andreas Ernst | IT Spektrum
 Postfach 5, 65612 Beselich
 Schupbacher Str. 32, 65614 Beselich, Germany
 Tel: +49-6484-91002 Fax: +49-6484-91003
 a...@ae-online.de | www.ae-online.de
 www.tachyon-online.de



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


   
   
--
Howard M. Lewis Ship
   
Looking for Clojure engagements: coding, architecture, mentoring 
  more!
   
Creator of Apache Tapestry
   
(971) 678-5210
http://howardlewisship.com
@hlship
   
  
 

Re: [Vote] Switch to release candidate

[Lance Java]

Lance S. +1 (non-binding)
 On 13 Jul 2015 20:53, Thiago H de Paula Figueiredo thiag...@gmail.com
wrote:

 Hi!

 I've fixed a couple of issues I considered showstoppers. 5.4 is long
 overdue, and if not perfect, nothing remaining (to my view) can't wait for
 a 5.4.1 or even a 5.5 (which, I would hope, we be months out, not years!).

 I would like the next tapestry release (not yet generated) to be rc-1.  As
 per our procedures, we have a binding vote to switch from beta to rc, then
 a new standard vote for a public release.

 Vote to run for three days. I believe we need at least 3 +1's from PMC
 members, and no -1's.

 Thiago H. de Paula Figueiredo: +1 (binding)

 --
 Thiago H. de Paula Figueiredo
 Tapestry, Java and Hibernate consultant and developer
 http://machina.com.br

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

Re: [VOTE] 5.4-rc-1

[Lance Java]

Lance S: +1 (non-binding)
On 27 Oct 2015 18:11, "Kalle Korhonen"  wrote:

> Kalle Korhonen: +1 (non-binding)
>
> On Tue, Oct 27, 2015 at 10:25 AM, Jochen Kemnade 
> wrote:
>
> > Jochen Kemnade: +1 (binding)
> >
> > Jochen Kemnade  schrieb am Mo., 26. Okt. 2015 um
> > 18:28 Uhr:
> >
> > > Hi,
> > >
> > > I've created and uploaded a release of Tapestry 5.4-rc-1, ready to be
> > > voted upon.
> > >
> > > The source and binary downloads are uploaded to:
> > >
> > > https://dist.apache.org/repos/dist/dev/tapestry
> > >
> > > and the Maven artifacts staged to:
> > >
> > > https://repository.apache.org/content/repositories/staging
> > >
> > > Please examine these files to determine if the new release, 5.4-rc-1,
> > > is ready.
> > >
> > > I've also created a 5.4-rc-1 tag in Git:
> > >
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.4-rc-1
> > >
> > > Vote will run for three days at least; On a successful vote, I'll
> > > release the Maven artifacts, and move the source and javadoc
> > > distributions from these directories to the proper distribution
> > > directories and update the Tapestry site documentation, and send out
> > > appropriate notifications.
> > >
> > > Jochen
> > >
> > >
> > >
> > >
> >
>

Re: [VOTE] 5.4.2

[Lance Java]

Lance S. +1 (non-binding)

On 10 Apr 2017 12:19, "Jochen Kemnade"  wrote:

> I've created and uploaded a release of Tapestry 5.4.2, ready to be voted
> upon.
>
> The source, binary, and documentation archives have been uploaded to:
>
> https://dist.apache.org/repos/dist/dev/tapestry
>
> and the Maven artifacts staged to:
>
>
> https://repository.apache.org/content/repositories/staging/
> org/apache/tapestry/
>
> Please examine these files to determine if the new release, 5.4.2, is
> ready.
>
> I've also created a 5.4.2 tag in Git:
>
>
> https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=
> log;h=refs/tags/5.4.2
>
> Vote will run for three days and requires majority approval from
> the PMC: At least 3 binding +1 votes and more positive than
> negative binding votes.
>
> On a successful vote, I'll release the Maven artifacts, the archives,
> and make the necessary updates to JIRA and the Tapestry site.
>
> Only votes cast by Tapestry PMC members are binding, but input
> from the community is highly valued. Please indicate whether your
> vote is binding or not after your full name (as it will appear in
> the end-of-vote summary).
>

Re: Getting ready for 5.4.2

[Lance Java]

There's a typescript gradle plugin

https://github.com/sothmann/typescript-gradle-plugin

The Tapestry build could use this at build time to convert Typescript to
Javascript which is published to maven central. So downstream consumers
wouldn't need nodejs installed

On 4 Apr 2017 12:13 p.m., "Jochen Kemnade" 
wrote:

> Hi,
>
> Am 04.04.2017 um 13:05 schrieb Bob Harner:
>
>> As I understand it the Typescript compiler is written Typescript, which
>> can
>> be compiled to JavaScript, and then that compiled compiler can be run in
>> any compliant JavaScript engine, including Rhino that Tapestry already
>> employs as well as the Nashorn engine built into Java 8.
>>
>
> Not if they use Node API, for example for file access etc. But even if
> they do that, there are ways to get it to work. You could rely on Node
> being available on the PATH and just execute it, which is what
> tapestry-react [1] does.
> Or you could install a Node distribution on the fly and use that.
>
> Jochen
>
> [1] https://github.com/eddyson-de/tapestry-react
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>