Re: JIRA issues that don't affect 5.4

[Barry Books]

I added comments to 2099 and 2327 but I don't think I can update the
version. Both are easy to fix and I included suggestions for fixing them

On Monday, February 22, 2016, Jochen Kemnade 
wrote:

> Am 22.02.2016 um 13:40 schrieb Bob Harner:
>
>> I think a high percentage of those issues do affect 5.4. But I'm okay with
>> the bulk-close-candidate label part at least.
>>
>
> Yes, probably some of the issues do affect 5.4, that's why we're going to
> wait a few months between adding the label and actually closing the issues.
> That'll leave the reporters (or anyone else) enough time to update the
> "Affects Version/s" field.
>
> Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>

Re: Unable to create beta-3

[Barry Books]

I've run into this problem with the hibernate config file see

https://community.jboss.org/wiki/HibernateCoreMigrationGuide36

The namespace has changed to

http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd


On Fri, Feb 7, 2014 at 2:54 PM, Howard Lewis Ship hls...@gmail.com wrote:

 :tapestry-hibernate-core:test
 [WARN] DTDEntityResolver HHH000223: Recognized obsolete hibernate namespace
 http://hibernate.sourceforge.net/. Use namespace
 http://www.hibernate.org/dtd/ instead. Refer to Hibernate 3.6 Migration
 Guide!
 [WARN] ConnectionProviderInitiator HHH22: c3p0 properties were
 encountered, but the
 org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider
 provider class was not found on the classpath; these properties are going
 to be ignored.
 [INFO] HibernateSessionSourceTest Hibernate startup: 298 ms to configure,
 967 ms overall.
 [INFO] HibernateSessionSourceTest Configured Hibernate entities: (none)
 [WARN] DTDEntityResolver HHH000223: Recognized obsolete hibernate namespace
 http://hibernate.sourceforge.net/. Use namespace
 http://www.hibernate.org/dtd/ instead. Refer to Hibernate 3.6 Migration
 Guide!
 [WARN] ConnectionProviderInitiator HHH22: c3p0 properties were
 encountered, but the
 org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider
 provider class was not found on the classpath; these properties are going
 to be ignored.
 [INFO] HibernateSessionSourceTest Hibernate startup: 65 ms to configure,
 312 ms overall.
 [INFO] HibernateSessionSourceTest Configured Hibernate entities:
 org.example.app0.entities.User

 Tapestry Hibernate Internal APIs 

 org.apache.tapestry5.internal.hibernate.HibernateTransactionDecoratorImplTest.checked_exception_will_commit_transaction
   FAILED
 java.lang.RuntimeException at
 HibernateTransactionDecoratorImplTest.java:153
 Caused by: java.io.IOException at
 HibernateTransactionDecoratorImplTest.java:153

 Tapestry Hibernate Internal APIs 

 org.apache.tapestry5.internal.hibernate.HibernateTransactionDecoratorImplTest.runtime_exception_will_abort_transaction
FAILED
 java.lang.RuntimeException at
 HibernateTransactionDecoratorImplTest.java:124
 Caused by: java.io.IOException at
 HibernateTransactionDecoratorImplTest.java:124

 Tapestry Hibernate Internal APIs 

 org.apache.tapestry5.internal.hibernate.HibernateTransactionDecoratorImplTest.undecorated
 FAILED
 java.lang.RuntimeException at
 HibernateTransactionDecoratorImplTest.java:63
 Caused by: java.io.IOException at
 HibernateTransactionDecoratorImplTest.java:63

 Tapestry Hibernate Internal APIs 

 org.apache.tapestry5.internal.hibernate.HibernateTransactionDecoratorImplTest.void_method
 FAILED
 java.lang.RuntimeException at
 HibernateTransactionDecoratorImplTest.java:80
 Caused by: java.io.IOException at
 HibernateTransactionDecoratorImplTest.java:80

 Tapestry Hibernate Internal APIs 

 org.apache.tapestry5.internal.hibernate.HibernateTransactionDecoratorImplTest.void_method_with_param
  FAILED
 java.lang.RuntimeException at
 HibernateTransactionDecoratorImplTest.java:98
 Caused by: java.io.IOException at
 HibernateTransactionDecoratorImplTest.java:98

 11 tests completed, 5 failed
 :tapestry-hibernate-core:test FAILED

 FAILURE: Build failed with an exception.


 Thiago: I think these are related to your changes.  Please look into it if
 you can, and get back to me quickly if you are not able to look into it,
 and I will.

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

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

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

Re: [jira] [Created] (TAP5-2285) Tapestry-Hibernate hibernate-core-4.1.2 mysql bug

[Barry Books]

Not really the same problem but I also found Hibernate 4 does not work with
some earlier versions of Tomcat. Hibernate reports it cannot find the JNDI
database even though it is there. This appears to be a Tomcat problem and I
fixed it by upgrading to Tomcat 7.0.50.


On Thu, Feb 6, 2014 at 8:46 AM, George Christman (JIRA) j...@apache.orgwrote:

 George Christman created TAP5-2285:
 --

  Summary: Tapestry-Hibernate hibernate-core-4.1.2 mysql bug
  Key: TAP5-2285
  URL: https://issues.apache.org/jira/browse/TAP5-2285
  Project: Tapestry 5
   Issue Type: Bug
 Affects Versions: 5.4
 Reporter: George Christman


 A bug was found in hibernate-core-4.1.2 which causes the mysql driver not
 to be found in Tomcat. This bug has been resolved in more current versions.

 Could we upgrade hibernate-core to a more current version?

 Please see post
 https://forum.hibernate.org/viewtopic.php?p=2454336



 --
 This message was sent by Atlassian JIRA
 (v6.1.5#6160)

Re: The Bootstrap Backward Compatibility Problem

[Barry Books]

When I first wrote the tapestry-bootstrap module someone on the list
pestered me (thanks) to make it backward compatible with the current
components so you could have both Bootstrap and the older Tapestry
components on the same page. After some tinkering I discovered it was for
the most part possible. The biggest issue seems to be something in
Prototype causes a problem with the Bootstrap menus.

I've been using Bootstrap the since the 1.0 version and I'm currently
porting my last non Bootstrap web site to 5.4 and Bootstrap. I'm a big
Bootstrap fan but I can see it's not for everybody. I would also say for
better or worse the Bootstrap project does seem to worry too much about
backward compatibility.

At this point I'm happy with the direction of Tapestry and I think the
addition of Bootstrap solves more problems than it causes.

However I do think it could be better so here is my suggestion

1. Components should have no framework specific html elements and no css
2. I would make a data attribute called data-tapestry-type contain the
Tapestry component type.
3. Attach a mixin to all components that calls a service to add the
framework specific markup
4. Create a strategy service so various framework markups can be supported.
5. Each framework strategy service is a pipeline that takes a markup writer
and modifies the DOM as needed.
6. Create a property to define the default framework.

This allows any component to be rendered for any framework. It also
supports new components by adding services to the framework pipeline. You
can also contribute site specific customization of components. Lastly it
solves the markup backward compatibility problem because the default markup
is not specific to any framework and does not need to change.

This is similar to how the current tapestry-bootstrap modules works.

 The backend implementation can be a bit complex but most developers could
just drop in the framework module they want and the site magically converts
to that framework.

I did have some issues with the existing components when I went down this
path. There are some inconsistencies in when components add to the markup
writer but I think these could all be resolved. For example the outer
element should always be started before the mixin's beginRender method.
With a bit more consistency I think all framework specific markup could be
added with a mixin like

private Element outerElement;

@Environmental
private Framework framework;

@BeginRender
void beginRender(MarkupWriter writer) {
outerElement = writer.getElement();
}

@CleanupRender
void cleanupRender(MarkupWriter writer) {
framework.cleanup(framework, outerElement, writer);
}

Personally I would not advocate this change at this point. I think the
current 5.4 path is fine. If there is enough interest it might be
interesting in 5.4.1 and along with a tapestry-legacy framework module
could be helpful for people with older sites wanting to upgrade to 5.4

Barry


On Tue, Oct 22, 2013 at 11:59 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote:

 I am glad I am not the only one seeing this.
 It's not an easy problem to solve though.
 And, I am not one of those people that want 100% compatibility
 (hence I would gladly have Tapestry 6)

 I am in the process of converting an app to Tapestry 5.4,
 Having never used bootstrap, and not being a web designer myself,
 it presented a challenge, but not insurmountable one.
 The ongoing problem is indeed that the markup will change over time,
 and maintaining compatibility will be problematic.

 Right now, My particular issue is beaneditform with p: parameters
 isn't generating proper bootstrap markup.
 I am sure there will be other issues like this that I discover.

 On Oct 22, 2013, at 9:21 PM, Bob Harner wrote:

  For new projects it's very nice that Tapestry 5.4 uses and includes
  Bootstrap. But for existing 5.2 and 5.3 projects not already using
  Bootstrap (which is probably the vast majority), upgrading to 5.4
 requires
  a burdensome amount of CSS and HTML changes. Even if you go the route of
  eliminating the Bootstrap CSS file (which for large existing apps may be
  the only practical option), you still need to come up with all new CSS
  rules for the built-in Tapestry components -- Grid, BeanEditor, Palette,
  etc -- on your own.
 
  Back in August, Tapestry 5.4-alpha-18 switched from Bootstrap 2 to
  Bootstrap 3. Since 2 and 3 are incompatible, this meant Howard had to do
  another round of disruptive, non-backward-compatible changes to Tapestry
  components (see his commits between Aug 21 and Sep 3, for TAP5-2151), and
  all users tracking the alphas had to adapt their apps to use Bootstrap 3.
  What happens if you wanted to stick with Bootstrap 2? What happens when
  Bootstrap 4 comes out?
 
  As we all know, one of Tapestry's core principles is backward
  compatibility -- which means upgrades should be very easy.
 
  It occurred to me that Tapestry already has a built-in means for
 rendering
  alternate content 

Re: Proposal for ObjectFactory service in 5.4

[Barry Books]

finally got around to this and it does not work in 5.4


   -
   
org.apache.tapestry5.ioc.internal.services.ValueObjectProvider.provide(ValueObjectProvider.java:47)
   -
   
org.apache.tapestry5.ioc.internal.services.MasterObjectProviderImpl$1.invoke(MasterObjectProviderImpl.java:52)
   -
   
org.apache.tapestry5.ioc.internal.services.MasterObjectProviderImpl.provide(MasterObjectProviderImpl.java:45)
   - com.trsvax.pages.work.WorkView.onSuccess(WorkView.java:214)

*
*
because

47https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=blob;f=tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/services/ValueObjectProvider.java;h=828c6697af39dc36775aa4647b2ea29ca7c173b3;hb=HEAD#l47
   Value annotation =
annotationProvider.getAnnotation(Value.class);

but this does

invoice = provider.provide(Invoice.*class*, *new* AnnotationProvider() {


  @Override

  *public* T *extends* Annotation T getAnnotation(ClassT arg0) {

  *return* *null*;

  }

}, *null*, *true*);


While it works it's not the most convenient method for creating a new
object. I'm guessing your code works in 5.3. Should I create a JIRA?


On Mon, Sep 30, 2013 at 8:25 AM, Thiago H de Paula Figueiredo 
thiag...@gmail.com wrote:

 On Mon, 30 Sep 2013 09:50:14 -0300, Barry Books trs...@gmail.com wrote:

  Thanks for the example. I think that will meet my needs.


 Yay! :)


  I don't think I
 would have ever figured that out from the existing documentation.


 It's one of the hidden gems of Tapestry and Tapestry-IoC. I just
 remembered it because I remembered that in Tapestry-IoC you can provide any
 injection yourself as long as you contributed something to some service,
 then I remembered about ObjectProvider and MasterObjectProvider.


 --
 Thiago H. de Paula Figueiredo

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

Re: Proposal for ObjectFactory service in 5.4

[Barry Books]

found NullAnnotaionProvider which is somewhat better

invoice = provider.provide(Invoice.*class*, *new* NullAnnotationProvider(),
*null*, *true*);


On Mon, Oct 14, 2013 at 7:45 AM, Barry Books trs...@gmail.com wrote:

 finally got around to this and it does not work in 5.4


-

 org.apache.tapestry5.ioc.internal.services.ValueObjectProvider.provide(ValueObjectProvider.java:47)
-

 org.apache.tapestry5.ioc.internal.services.MasterObjectProviderImpl$1.invoke(MasterObjectProviderImpl.java:52)
-

 org.apache.tapestry5.ioc.internal.services.MasterObjectProviderImpl.provide(MasterObjectProviderImpl.java:45)
- com.trsvax.pages.work.WorkView.onSuccess(WorkView.java:214)

 *
 *
 because

  
 47https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=blob;f=tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/services/ValueObjectProvider.java;h=828c6697af39dc36775aa4647b2ea29ca7c173b3;hb=HEAD#l47
 Value annotation = annotationProvider.getAnnotation(Value.class);

 but this does

 invoice = provider.provide(Invoice.*class*, *new* AnnotationProvider() {


   @Override

   *public* T *extends* Annotation T getAnnotation(ClassT arg0) {

   *return* *null*;

   }

 }, *null*, *true*);


 While it works it's not the most convenient method for creating a new
 object. I'm guessing your code works in 5.3. Should I create a JIRA?


 On Mon, Sep 30, 2013 at 8:25 AM, Thiago H de Paula Figueiredo 
 thiag...@gmail.com wrote:

 On Mon, 30 Sep 2013 09:50:14 -0300, Barry Books trs...@gmail.com wrote:

  Thanks for the example. I think that will meet my needs.


 Yay! :)


  I don't think I
 would have ever figured that out from the existing documentation.


 It's one of the hidden gems of Tapestry and Tapestry-IoC. I just
 remembered it because I remembered that in Tapestry-IoC you can provide any
 injection yourself as long as you contributed something to some service,
 then I remembered about ObjectProvider and MasterObjectProvider.


 --
 Thiago H. de Paula Figueiredo

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

Re: Proposal for ObjectFactory service in 5.4

[Barry Books]

passing null for the annotation provider results in a null pointer
exception in 5.4


On Mon, Oct 14, 2013 at 9:06 AM, Thiago H de Paula Figueiredo 
thiag...@gmail.com wrote:

 On Mon, 14 Oct 2013 09:56:05 -0300, Barry Books trs...@gmail.com wrote:

  found NullAnnotaionProvider which is somewhat better

 invoice = provider.provide(Invoice.***class*, *new*
 NullAnnotationProvider(),
 *null*, *true*);


 Or just pass null. As I said before in this thread, I don't see the need
 for a second way/service for providing objects. Maybe just another method
 in ObjectLocator with fewer parameters (just the type), passing default
 values.


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


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

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

[Barry Books]

Here are my thoughts on what a GitHub list would be and how it wold work.

GitHub has a feature called gh-pages. If you have a branch called gh-pages
GitHub will build a website from markdown files. Markdown is a simple
markup language. The idea is any one that wants to add their module creates
ticket asking to be a contributor then creates a documentation page and a
repository link. This would provide a list of 3rd party modules with the
data being maintained by the owner of the  module.

There are no requirements to host your project on Github and in fact there
is a browser interface for doing this so you would not even need git to
participate. Github also allows an organization to own a repository so it's
possible to delegate the responsibilities and owners can come and go.

I also see benefit in having a Tapestry based site like ComponentWorld and
I don't see the two as mutually exclusive. In fact I believe the Github
list could be the backend data store for a site like ComponentWorld because
there is be a description of the module in markdown and there is plenty of
information in a POM file. I also hope other applications would find this
data useful and I'm thinking about how I could use it if I write a
distributed documentation module.

Barry




On Thu, Oct 10, 2013 at 4:10 AM, Ulrich Stärk u...@spielviel.de wrote:

 I just want to point apache-extras.org out as a place for where products
 that are Apache-related but
 not part of Apache products can be hosted. It is based on Google code IIRC.

 Uli

 On 2013-10-09 12:50, Barry Books wrote:
  Lenny I agree with some of what you say and I have a few comments because
  I've been thinking about this also. I don't really have a problem with 3
  CDI implementations but I don't think I could find any of them. I think
  there needs to be some repository of 3rd party modules and I don't think
  the apache site is the place for that. I've been thinking about creating
 a
  github project and using that as a way to document what's available. If
 you
  have a 3rd party module you could be a contributor and I think it would
 be
  pretty easy to create one place to go for info, create bug reports etc.
 
  I think this could be one step to more cooperation.
 

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

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

[Barry Books]

Lenny I agree with some of what you say and I have a few comments because
I've been thinking about this also. I don't really have a problem with 3
CDI implementations but I don't think I could find any of them. I think
there needs to be some repository of 3rd party modules and I don't think
the apache site is the place for that. I've been thinking about creating a
github project and using that as a way to document what's available. If you
have a 3rd party module you could be a contributor and I think it would be
pretty easy to create one place to go for info, create bug reports etc.

I think this could be one step to more cooperation.

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

[Barry Books]

I think with maven central and github the parts to start something are
already here. I'd say start building on that and see where it goes.




On Wed, Oct 9, 2013 at 6:51 AM, Alessio Gambi agamb...@gmail.com wrote:

 As I said to HLS when we met in London some years ago, we need an open
 MarketPlace where people can easily do their own business: sell software,
 consult experts, browse catalogs of components/pages/services etc.


 As I see people rising the picks and flames let me also add that:
 - a market place can host/link also open and free projects

 - users can 'vote' the quality of the published artifacts, and express
 their opinions

 - developers can have some feedback on their work

 - add here what you like 


 Moreover, despite the failures of 90's-style components market places, now
 everybody is used to AppStores and easy to go solutions that perfectly fit
 the ability of tapestry to embrace new components and module 'almost' for
 free.

 Of course it would be great to have it running on tapestry  ( I have
 in mind several reasons why this choice should benefit to everybody)

 BTW, I am also of the idea that, no matter its implementation, such kind
 of things should not be hosted on Apache premises


 -- Alessio

 On 9-ott-2013, at 12:50, Barry Books trs...@gmail.com wrote:

  Lenny I agree with some of what you say and I have a few comments because
  I've been thinking about this also. I don't really have a problem with 3
  CDI implementations but I don't think I could find any of them. I think
  there needs to be some repository of 3rd party modules and I don't think
  the apache site is the place for that. I've been thinking about creating
 a
  github project and using that as a way to document what's available. If
 you
  have a 3rd party module you could be a contributor and I think it would
 be
  pretty easy to create one place to go for info, create bug reports etc.
 
  I think this could be one step to more cooperation.

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

Re: Proposal for ObjectFactory service in 5.4

[Barry Books]

Thanks for the example. I think that will meet my needs. I don't think I
would have ever figured that out from the existing documentation.


On Mon, Sep 30, 2013 at 6:21 AM, Thiago H de Paula Figueiredo 
thiag...@gmail.com wrote:

 On Sat, 28 Sep 2013 11:20:21 -0300, Barry Books trs...@gmail.com wrote:

  I think we are talking about two different things here or there is a
 Tapestry feature I don't know about.


 I'm not sure you tried to understand what I suggested you in my previous
 message.


  I'm looking for a feature that will
 return a new Plain Old Object from an Interface. A simple example:

 Map map = objectFactory.build(Map.class)**;


 I already know what you wanted and you just confirmed it now. I just
 suggested you to, instead of creating a new service just for instantiating
 interfaces, to reuse ObjectProvider and MasterObjectProvider instead. They
 have a scope which is a little broader than what you want: give it a type
 and it'll return (or not) an object of that type. The only difference is
 that in your service the contribution can only provide one type, while an
 ObjectProvider can provide many.

 Here's one example:

 In a module class:

 public static void contributeMasterObjectProvider**(OrderedConfiguration*
 *ObjectProvider configuration) {
 final ObjectProvider mapProvider = new ObjectProvider() {
 public T T provide(ClassT objectType,
 AnnotationProvider annotationProvider,
 ObjectLocator locator) {
 Object newObject = null;
 if (objectType == Map.class) {
 newObject = new HashMap();
 }
 return (T) newObject;
 }
 };
 configuration.add(Map, mapProvider);
 }

 Now you can inject the MasterObjectProvider service, which is part of
 Tapestry-IoC, and use it this way to get a Map instance:

 Map map1 = masterObjectProvider.provide(**Map.class, null, null, true);
 Map map2 = masterObjectProvider.provide(**Map.class, null, null, true);
 // prints 'true' because each time you call MasterObjectProvider.provide()
 and your ObjectProvider is the one who returns
 // the instance, it returns a new one.
 System.out.println(map1 != map2);

 You can even @Inject Maps now!

 @Inject
 private Map map1;

 @Inject
 private Map map2;

 Object onActivate(EventContext context) {
 System.out.println(map1 != map2); // prints 'true'
 ...
 }

 So, in summary, I'm against Barry's suggestion because the ObjectProvider/
 **MasterObjectProvider dynamic duo already implements what you want and
 we would otherwise have two differents services to do the same thing.


 --
 Thiago H. de Paula Figueiredo

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

Re: Proposal for ObjectFactory service in 5.4

[Barry Books]

I think we are talking about two different things here or there is a
Tapestry feature I don't know about. I'm looking for a feature that will
return a new Plain Old Object from an Interface. A simple example:

Map map = objectFactory.build(Map.class);

The service would know how to do this because I have the following
configuration:

configuration.add(Map.class,HashMap.class);

So in this example the Map instance would be a new HashMap instance.

I realize I can build something that does this with the current version of
Tapestry but I don't know any existing service that does this out of the
box.

I think in order to build a set of Modules that cooperate thru Interfaces
there needs to be a common way to instantiate real classes from Interfaces.



On Fri, Sep 27, 2013 at 7:05 PM, Thiago H de Paula Figueiredo 
thiag...@gmail.com wrote:

 On Fri, 27 Sep 2013 18:09:13 -0300, Barry Books trs...@gmail.com wrote:

  It useful for library modules because you can build a set of pages,
 components and classes that work on Interfaces instead of concrete
 classes.
 The application can just implement the interfaces and contribute them. In
 my case about I have an Invoice interface that's is defined in a shop
 module. The shop module just operates on the Interface. Then I have a web
 app that implements that Interface in my case as a DynamoDB object.
 Others could implement it as a JPA or Hibernate object.


 A library module can define interfaces and @Inject them without the module
 itself defining the service implementations. Of course, to test or use it,
 you'll need to create and define implementations for that services, maybe
 mocks in some module class outside the library component that defines that
 inteface, but that's not a requirement for building a module library. All
 you need to do is to *not* define the service and let other module class
 (maybe AppModule) do that. If no one actually provides a service
 implementation, Tapestry will raise an exception explaining that.


  There are several reasons it needs to be in the core.

 1. It would be great if BeanEditForm used it so  BeanEditForm could work
 with interfaces.


 Actually, implementing BeanModel yourself or decorating one created
 through BeanModelSource and passing it to BeanEditForm and BeanEditor,
 probably by decorating or advising the BeanModelSource service, you can
 implement the BeanModel.newInstance() method (or decorate the BeanModel
 created by BeanModelSource and override the newInstance() method) and have
 it instantiate any object you want automatically (as long at it implements
 the interface, of course).


  2. If you are going to build a Modules based on Interfaces it needs to be
 in the core otherwise everyone will end up with a different
 implementation and they don't interoperate.


 I'm sorry, I'm not following you here, maybe because of my explanation
 below.


  3. It's easier to use in pages/components than locator.


 Agreed. If it's just about instantiating objects based on interfaces, I've
 just discovered ObjectProvider and MasterObjectProvider (which is basically
 a façade around the list of ObjectProviders), which I believe may fit the
 scenario you're thinking:

 /**
  * Object providers represent an alternate way to locate an object
 provided somewhere in the {@link
  * org.apache.tapestry5.ioc.**Registry}. Instead of using a just the
 service id to gain access to a service within the
  * Registry, object providers in different flavors are capable of vending,
 or even creating, objects of disparate types
  * from disparate sources.
  * p/
  * Object providers are consulted in a strict order, and the first
 non-null result is taken.
  * p/
  * In many cases, an object provider searches for additional annotations
 on the element (usually a parameter, or perhaps
  * a field) for which a value is required.
  */
 public interface ObjectProvider {
 T T provide(ClassT objectType, AnnotationProvider
 annotationProvider, ObjectLocator locator);

 }

  4. Tapestry is really good about using Interfaces to define functionality
 but it's difficult to do this in modules that define components. This
 solves most of the problems.


 I'm sorry, I'm not following you here, maybe because of my explanation
 above.

 By the way, for many scenarios, I've found that defining a chain of
 responsibility service (which Tapestry calls chain of command for some
 reason) the best way for dealing with stuff with distributed configuration
 instead of just defining a service. For example, your scenario deals with
 instantiating objects defining a given interface the library which defines
 this interface doesn't know the implementations. So I could define an
 InterfaceInstantiator service:

 @UsesOrderedConfiguration(**InterfaceInstantiator.class);
 public interface InterfaceInstantiatorT {
 /**
  * Instantiates an object of the given type. If this
 implementation doesn't support that type,
  * this method should

Proposal for ObjectFactory service in 5.4

[Barry Books]

I created a pretty simple service that's proven quite useful. The interface
is

*public* *interface* ObjectFactory {


 *public* T T build(ClassT clazz);

}


it's built on top of autobuild and since it's a service you can plug in
different factories. The one I have this


*public* *class* ObjectFactoryImplT *implements* ObjectFactory {

*private* *final* MapClass, Class config;

*private* *final* ObjectLocator locator;

 *public* ObjectFactoryImpl(MapClass,Class config, ObjectLocator locator)
{

*this*.config = config;

*this*.locator = locator;

}


 @SuppressWarnings({ unchecked, hiding })

@Override

*public* T T build(ClassT clazz) {

*if* ( config.containsKey(clazz) ) {

*return* (T) locator.autobuild(config.get(clazz));

}

*return* locator.autobuild(clazz);

}

}


This allows constructing real objects from interfaces with a config like
this:


@Contribute(ObjectFactory.*class*)

*public* *static* *void* contributeObjectFactory(MappedConfigurationClass,
Class configuration) {

configuration.add(PayLaterPayment.*class*, PayLaterPaymentDDB.*class*);

configuration.add(CreditCardPayment.*class*, CreditCardPaymentDDB.*class*);

configuration.add(PayPalPayment.*class*,PayPalPaymentDDB.*class*);

configuration.add(Invoice.*class*,InvoiceDDB.*class*);

configuration.add(InvoiceItem.*class*,LineItem.*class*);

}


What makes this useful is you can build modules that define interfaces and
then do things like


*public* *class* PayPalButton {

 @Parameter

*private* PaymentMethod payment;

 @Inject

*private* ObjectFactory objectFactory;

 *void* onSelectedFromPayPal() { payment = objectFactory
.build(PayPalPayment.*class*); }

}


I also think it would make BeanEditForm even more useful. If there any
interest I'll open a JIRA and add the code.


Thanks

Barry

Re: Proposal for ObjectFactory service in 5.4

[Barry Books]

I don't think so. In my case the value passed to the build method is always
type Class and the return is a new object based on the class type.

The strategy builder service takes a set of services and constructs a new
service that directs calls by the object type of the parameters. You can't
use it for this purpose because in this case the parameter type is always
the same i.e. Class


On Fri, Sep 27, 2013 at 2:21 PM, Thiago H de Paula Figueiredo 
thiag...@gmail.com wrote:

 Is it just me or what you're proposing is very similar to what
 StrategyBuilder.build(Class, Map) already does in the sense that you want
 to associate certain objets to a given class (the config field in
 ObjectFactoryImpl)?


 On Fri, 27 Sep 2013 15:32:00 -0300, Barry Books trs...@gmail.com wrote:

  I created a pretty simple service that's proven quite useful. The
 interface
 is

 *public* *interface* ObjectFactory {


  *public* T T build(ClassT clazz);


 }


 it's built on top of autobuild and since it's a service you can plug in
 different factories. The one I have this


 *public* *class* ObjectFactoryImplT *implements* ObjectFactory {

 *private* *final* MapClass, Class config;

 *private* *final* ObjectLocator locator;

  *public* ObjectFactoryImpl(MapClass,**Class config, ObjectLocator
 locator)
 {

 *this*.config = config;

 *this*.locator = locator;


 }


  @SuppressWarnings({ unchecked, hiding })

 @Override

 *public* T T build(ClassT clazz) {

 *if* ( config.containsKey(clazz) ) {

 *return* (T) locator.autobuild(config.get(**clazz));

 }

 *return* locator.autobuild(clazz);


 }

 }


 This allows constructing real objects from interfaces with a config like
 this:


 @Contribute(ObjectFactory.***class*)

 *public* *static* *void* contributeObjectFactory(**
 MappedConfigurationClass,
 Class configuration) {

 configuration.add(**PayLaterPayment.*class*, PayLaterPaymentDDB.*class*);

 configuration.add(**CreditCardPayment.*class*,
 CreditCardPaymentDDB.*class*);

 configuration.add(**PayPalPayment.*class*,**PayPalPaymentDDB.*class*);

 configuration.add(Invoice.***class*,InvoiceDDB.*class*);

 configuration.add(InvoiceItem.***class*,LineItem.*class*);


 }


 What makes this useful is you can build modules that define interfaces and
 then do things like


 *public* *class* PayPalButton {

  @Parameter

 *private* PaymentMethod payment;

  @Inject

 *private* ObjectFactory objectFactory;

  *void* onSelectedFromPayPal() { payment = objectFactory
 .build(PayPalPayment.*class*); }


 }


 I also think it would make BeanEditForm even more useful. If there any
 interest I'll open a JIRA and add the code.


 Thanks

 Barry



 --
 Thiago H. de Paula Figueiredo

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

Manifest line length problem

[Barry Books]

I had a module class with a package name the resulted in a class path of
more than 72 characters. Apparently the Manifest spec says this:

Name-Value pairs and SectionsBefore we go to the details of the contents of
the individual configuration files, some format convention needs to be
defined. In most cases, information contained within the manifest file and
signature files is represented as so-called name: value pairs inspired by
the RFC822 standard.  We also call these pairs headers or attributes.

Groups of name-value pairs are known as a section. Sections are separated
from other sections by empty lines.

Binary data of any form is represented as base64. Continuations are
required for binary data which causes line length to exceed 72 bytes.
Examples of binary data are digests and signatures.


Note the max line length is 72 bytes. Maven was cleaver enough to split my
package name into two lines but apparently Tapestry does not do the right
thing and does not load the module. Of course everything works fine during
development and it's only when you push to production that you find this.

It's not completely clear to me the spec really means a 72 character line
but it was good enough for the mainframe so I guess it's good enough for
Java.

Should I file a JIRA for this?

Re: Manifest line length problem

[Barry Books]

I'm inclined to agree with that. To me this part of the spec only applies
to binary data which means maven is wrong

On Wednesday, September 25, 2013, Howard Lewis Ship wrote:

 Tapestry uses the JDK code to read the Manifest files so I suspect this is
 a problem creating the manifest rather than Tapestry reading it.


 On Wed, Sep 25, 2013 at 6:03 AM, Barry Books trs...@gmail.comjavascript:;
 wrote:

  I had a module class with a package name the resulted in a class path of
  more than 72 characters. Apparently the Manifest spec says this:
 
  Name-Value pairs and SectionsBefore we go to the details of the contents
 of
  the individual configuration files, some format convention needs to be
  defined. In most cases, information contained within the manifest file
 and
  signature files is represented as so-called name: value pairs inspired
 by
  the RFC822 standard.  We also call these pairs headers or attributes.
 
  Groups of name-value pairs are known as a section. Sections are
 separated
  from other sections by empty lines.
 
  Binary data of any form is represented as base64. Continuations are
  required for binary data which causes line length to exceed 72 bytes.
  Examples of binary data are digests and signatures.
 
 
  Note the max line length is 72 bytes. Maven was cleaver enough to split
 my
  package name into two lines but apparently Tapestry does not do the right
  thing and does not load the module. Of course everything works fine
 during
  development and it's only when you push to production that you find this.
 
  It's not completely clear to me the spec really means a 72 character line
  but it was good enough for the mainframe so I guess it's good enough for
  Java.
 
  Should I file a JIRA for 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

Re: [jira] [Created] (TAP5-2187) CSS relative URL rewriting isn't lenient enough

[Barry Books]

I could go either way on this but I can see why you want to turn this off.
FYI I don't deploy my GWT client code thru Tapestry at all. Is there any
reason why you do?


On Tue, Sep 24, 2013 at 7:33 AM, Thiago H de Paula Figueiredo 
thiag...@gmail.com wrote:

 On Mon, 23 Sep 2013 21:43:55 -0300, Lenny Primak lpri...@hope.nyc.ny.us
 wrote:

  I can't.  The whole tree gets reworked by the GWT compiler plugin at the
 end. Putting an extra all-or-nothing check for CSS just makes Tapestry
 harder to use with no real benefit on the other side.
 Also, this is clearly incompatible with Tapestry's previous behavior.


 I agree with Lenny about this. The normal behavior of CSS is to not fail
 when some linked resource isn't found.


 --
 Thiago H. de Paula Figueiredo

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

Re: [jira] [Created] (TAP5-2187) CSS relative URL rewriting isn't lenient enough

[Barry Books]

I've put GWT projects in their own war and included them with Tapestry
projects. When I include them I usually put them in a GWT directory and
tell Tapestry to ignore it.


On Tue, Sep 24, 2013 at 11:35 AM, Lenny Primak lpri...@hope.nyc.ny.uswrote:

 Because the GWT parts talk to the Tapestry parts, so they have to be in
 the same relative path.
 Also, Tapestry has some nice things like forever-caching etc. that I like
 to take advantage of

 On Sep 24, 2013, at 8:49 AM, Barry Books wrote:

  I could go either way on this but I can see why you want to turn this
 off.
  FYI I don't deploy my GWT client code thru Tapestry at all. Is there any
  reason why you do?
 
 
  On Tue, Sep 24, 2013 at 7:33 AM, Thiago H de Paula Figueiredo 
  thiag...@gmail.com wrote:
 
  On Mon, 23 Sep 2013 21:43:55 -0300, Lenny Primak 
 lpri...@hope.nyc.ny.us
  wrote:
 
  I can't.  The whole tree gets reworked by the GWT compiler plugin at the
  end. Putting an extra all-or-nothing check for CSS just makes Tapestry
  harder to use with no real benefit on the other side.
  Also, this is clearly incompatible with Tapestry's previous behavior.
 
 
  I agree with Lenny about this. The normal behavior of CSS is to not fail
  when some linked resource isn't found.
 
 
  --
  Thiago H. de Paula Figueiredo
 
 
 --**--**-
  To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org
 dev-unsubscr...@tapestry.apache.org
  For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 


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

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

[Barry Books]

The 5.3 version of tapestry-bootstrap is in maven central but I'm not
really working on it anymore. At first I was just going to drop the project
since Tapestry 5.4 converted to Bootstrap but I've found I need various
add-ons which I think will be useful to others. For example I have
components/mixins for all the Bootstrap javascript components. I'm using it
on a project I'm converting to 5.4 and when I'm finished I'll push it up to
GitHub.


On Wed, Sep 18, 2013 at 8:54 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote:

 Speaking of that, what's the status of tapestry-bootstrap and T5.4?
 And also is it in maven central yet?



 On Sep 18, 2013, at 7:53 PM, Barry Books trs...@gmail.com wrote:

  I was planing on using modernizr to detect if type=date is supported.
  I've also added min and max to the mixin since they are also supported by
  HTML5. I'm sure I'll put in my Bootstrap library and I'll submit it for
  inclusion in 5.4 but it's not at all compatible with the old DateField.
 
 
 
 
  On Wed, Sep 18, 2013 at 7:12 PM, Geoff Callender 
  geoff.callender.jumpst...@gmail.com wrote:
 
  iDevices have their own, great, touch-friendly, date picker for HTML5
  type=date, so maybe what's needed is to detect the media type before
  deciding whether to display a JavaScript datepicker.
 
  Similarly, recent releases of Chrome handle type=date with a pretty
 good
  picker, so maybe what's needed is a parameter to declare which browsers
 to
  NOT override with our picker.
 
 
 
  On 19 September 2013 08:24, Barry Books 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

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

[Barry Books]

I was planing on using modernizr to detect if type=date is supported.
I've also added min and max to the mixin since they are also supported by
HTML5. I'm sure I'll put in my Bootstrap library and I'll submit it for
inclusion in 5.4 but it's not at all compatible with the old DateField.




On Wed, Sep 18, 2013 at 7:12 PM, Geoff Callender 
geoff.callender.jumpst...@gmail.com wrote:

 iDevices have their own, great, touch-friendly, date picker for HTML5
 type=date, so maybe what's needed is to detect the media type before
 deciding whether to display a JavaScript datepicker.

 Similarly, recent releases of Chrome handle type=date with a pretty good
 picker, so maybe what's needed is a parameter to declare which browsers to
 NOT override with our picker.



 On 19 September 2013 08:24, Barry Books 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

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

[Barry Books]

I agree with Geoff. It's easy to include the core stack in a Layout
component.


On Wed, Sep 18, 2013 at 7:48 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote:

 Technically I agree but it breaks compatibility. So I reluctantly disagree.



 On Sep 18, 2013, at 7:39 PM, Geoff Callender 
 geoff.callender.jumpst...@gmail.com wrote:

  What changed? The JIRA issue says fixed but there's no info about how.
 
  IMHO, it was a FABULOUS decision to emit minimal css classes and NO
  stylesheet. Developers are free to add the core stack if they wish and
 free
  to add refining css classes to the tml.
 
  Who agrees/disagreees?
 
 
  On 12 September 2013 11:57, Hudson (JIRA) 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
 

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

Re: [5.4] Problems with the asset checksums and relative paths based on them

[Barry Books]

I use CKEditor and had the same problem. I was able to use Thiago's code
and got it working


On Mon, Sep 16, 2013 at 12:55 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote:

 JIRA created: https://issues.apache.org/jira/browse/TAP5-2185

 On Sep 16, 2013, at 8:47 AM, Thiago H de Paula Figueiredo wrote:

  On Mon, 16 Sep 2013 01:00:20 -0300, Lenny Primak lpri...@hope.nyc.ny.us
 wrote:
 
  Is there a JIRA for this?
 
  I don't think so.
 
  I would like to watch the resolution for this, as this is hitting me
 with the GWT / SmartGWT integration
 
  While a permanent solution isn't provided in Tapestry itself, you can
 adapt the one I wrote for tapestry-wymeditor:
 https://github.com/thiagohp/tapestry-wymeditor/blob/master/src/main/java/br/com/arsmachina/tapestry_wymeditor/services/WymeditorRequestFilter.java
 .
 
  --
  Thiago H. de Paula Figueiredo
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
  For additional commands, e-mail: dev-h...@tapestry.apache.org
 


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

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

[Barry Books]

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.uswrote:

 High because we have to get this done for 5.4. Probably start with
 incorporating the new datefield into FlowLogix though. Not sure patch makes
 sense in this case though. But I am willing to work on the datefield
 modernization.

 On Sep 16, 2013, at 7:02 PM, Howard Lewis Ship hls...@gmail.com wrote:

  What are the chances of a patch?
 
  I'm stretched really, really thin right now. More so than usual. I'm
  anything but a fan of the built-in DateField component for any number of
  reasons, but I can't squeeze blood from a stone.
 
 
  On Mon, Sep 16, 2013 at 7:12 PM, Lenny Primak le...@flowlogix.com
 wrote:
 
  Just for planning purposes, what are the changes of datepicker being
  replaced to bootstrap (or any other modern one)
  prior to T5.4 release?
 
  I need to plan this out, because current T5.4 datepicker is unusable for
  us, so if the new datepicker isn't in the cards,
  we need to start writing our own datepicker integration.
 
  Thank you.
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
  For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 
  --
  Howard M. Lewis Ship
 
  Creator of Apache Tapestry
 
  The source for Tapestry training, mentoring and support. Contact me to
  learn how I can get you up and productive in Tapestry fast!
 
  (971) 678-5210
  http://howardlewisship.com

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

Re: [5.4] Problems with the asset checksums and relative paths based on them

[Barry Books]

If you have file a b and c. The page includes a which then includes b and c
but in your case with a's checksum. If Tapestry just returned b and c with
a's checksum everything would work fine. The only problem would be if you
change b or c without changing a. I agree this could be a problem but if
you are using a library with releases I would say the odds of this
happening are low and is easily fixed by just changing a.

In other words what's the benefit of the 404? The checksum is not meant to
be a security mechanism.


On Thu, Sep 12, 2013 at 6:54 AM, Thiago H de Paula Figueiredo 
thiag...@gmail.com wrote:

 On Wed, 11 Sep 2013 19:41:40 -0300, Barry Books trs...@gmail.com wrote:

  Perhaps a dumb question but why does the checksum need to match for
 Tapestry to return the file? The only problem I can think of is if the
 included file changes but the main file does not then the cached file
 might be used.


 What do you mean by included file and main file?


  I would think that's unlikely to happen


 Actually, browsers not getting updated JS, CSS and image files after they
 were changed in the server is quite common without some mechanism like
 that. In T5.1 projects, many times I've had to ask the testers to clear
 their caches because they were testing the fix and the problem was still
 appearing because of the browser cache.

 I've actually fixed my problem by creating a request filter that checks
 for requests to files dynamically included by WYMeditor, find the original
 files in the classpath, generate a new Asset instance for them (which
 contains the right checksum) and redirects to it. Ugly, but fixes the
 problem. :)


 --
 Thiago H. de Paula Figueiredo

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

Re: [5.4] Problems with the asset checksums and relative paths based on them

[Barry Books]

if you have a url like a/123/b where 123 is the checksum of the parent file
then do a 301 to /a/123_456/b where 456 is the checksum of b. If b changes
then you can do another 301 to /a/123_789. If the parent file changes then
it's a different 301.


On Thu, Sep 12, 2013 at 1:26 PM, Howard Lewis Ship hls...@gmail.com wrote:

 No, I think redirect-to-correct-url is a good idea; I'm just not sure what
 the URL will look like.

 Ideally, we would rework /assets/modules/ to leverage this as well. May
 improve page-to-page transitions if the user agent doesn't even have to
 check to see if module resource has changed.


 On Thu, Sep 12, 2013 at 11:13 AM, Thiago H de Paula Figueiredo 
 thiag...@gmail.com wrote:

  Ok, I agree with you with the 301 vs 302 issue. I just didn't understand
  whether you agree with the redirect-to-the-correct-URL-**instead-of-404
  suggestion. :)
 
 
  On Thu, 12 Sep 2013 14:49:01 -0300, Howard Lewis Ship hls...@gmail.com
  wrote:
 
   Not a 301 and here's why.
 
  The full URL, with checksum, represents an immutable resource.
 
  Changing the content of that resource is really replacing it with a new
  immutable resource; that resource will have a different URL due to the
  checksum.
 
  The redirecting-thing attempts to resolve the resource from partial
  information: the path data. It redirects the current version of the
  resource, and that's fine.
 
  However, I would not want it to be a permanent redirect, since that
 might
  prevent the same user agent from downloading a newer version of the
  resource when that is available at a later date.
 
 
 
  On Thu, Sep 12, 2013 at 7:57 AM, Thiago H de Paula Figueiredo 
  thiag...@gmail.com wrote:
 
   On Thu, 12 Sep 2013 09:43:40 -0300, Barry Books trs...@gmail.com
  wrote:
 
   In other words what's the benefit of the 404? The checksum is not
 meant
 
  to be a security mechanism.
 
 
  After fixing my problem here and reading your message, I wonder if
  Tapestry should redirect to the correct asset URL with a HTTP Error 301
  (Moved permanently) code.
 
 
  --
  Thiago H. de Paula Figueiredo
 
  --**
  --**-
  To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apa**che.org
 http://apache.org
  dev-unsubscribe@**tapestry.apache.org
 dev-unsubscr...@tapestry.apache.org
  
 
 
  For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 
 
 
 
 
  --
  Thiago H. de Paula Figueiredo
 
  --**--**-
  To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org
 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: [5.4] Problems with the asset checksums and relative paths based on them

[Barry Books]

Perhaps a dumb question but why does the checksum need to match for
Tapestry to return the file? The only problem I can think of is if the
included file changes but the main file does not then the cached file might
be used. I would think that's unlikely to happen and could easily be solved
by just changing the main file. The current problem is difficult to solve.


On Wed, Sep 11, 2013 at 9:16 AM, Thiago H de Paula Figueiredo 
thiag...@gmail.com wrote:

 On Tue, 10 Sep 2013 22:25:18 -0300, Howard Lewis Ship hls...@gmail.com
 wrote:

  This is a tricky one to handle.


 Yep. I still couldn't find a good, simple solution yet. The whole
 classpath asset support code is built on the top of the checksums.


  It feels like we need yet another Asset URL path that works more like
 modules: no checksum in the URL and no far-future expires header, but
 maybe e-tags support.


 What about something like a simpleclasspath binding that does everything
 the normal classpath one does but without the checksum?


  Alternately, using the WYMeditor configuration, we could follow up on the
 idea I had on the user mailing list: an alternate asset URL that sends a
 proper redirect to the real asset.  So /X/meta/wymeditor/foo.css would be
 redirected to /assets.gz/meta/wymeditor/**abc123/foo.css.


 That's a good idea, but it wouldn't solve the problem I'm having now.


 --
 Thiago H. de Paula Figueiredo

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

Re: Why not to include html5shiv.js and respond.min.js ?

[Barry Books]

True enough and to have any chance you are going to want something like
this:

 configuration.add(JacquardConstants.XUACompatibleHeader,IE=edge);

*public* *class* XUACompatibleHeader *implements* RequestFilter {

*private* *static* *final* String HEADER_KEY = X-UA-Compatible;

*private*  *final* String headerValue;


 *public* XUACompatibleHeader(@Symbol(JacquardConstants.XUACompatibleHeader)
String headerValue) {

*this*.headerValue = headerValue;

}



*public* *boolean* service(Request request, Response response,
RequestHandler handler) *throws* IOException {

response.setHeader(HEADER_KEY, headerValue);

*return* handler.service(request, response);

}


}



On Fri, Aug 30, 2013 at 3:36 AM, Massimo Lusetti mluse...@gmail.com wrote:

 On Fri, Aug 30, 2013 at 10:11 AM, Dimitris Zenios 
 dimitris.zen...@gmail.com
  wrote:

 In order for bootstrap 3 to work on internet explorer version less than 9
  you need those two libraries.Below example was taken from bootstrap
  website.
 
 
 Yes, I must say that not everything will work BTW ...

 --
 Massimo Lusetti

Re: Discussion: Future of tapestry-test friends.

[Barry Books]

I have a few thoughts but they are conflicting.

1. Anything that makes testing easier would be welcome.
2. It would have to be beyond easy to create new test cases to make me want
to rewrite my old ones.
3. I'm sure (fill in you favorite language here) is great but I'm
mandated (It's more of a suggestion really) to use Java.
4. If I have to find Groovy programers they are going to know Grails.
5. I have enough trouble with Selenium running under Hudson on my build
machine. I don't really want to try and support something else also.

I can see this being used on new projects but I don't see much benefit to
existing ones.


On Thu, Aug 1, 2013 at 4:04 AM, Denis Delangle
denis.delangle...@gmail.comwrote:

 Hello,

 As a Tapestry user, I use tapestry-test to test my applications and my
 widgets libraries to validate migration from tapestry versions. I did
 it from tapestry 5.1 to 5.4 quite easily. I would be happy to
 integrate new technologies for the tests I will write in the future
 but I see absolutely no good reason to rewrite existing tests. Writing
 regression tests is an investment on the long term, having to rewrite
 them because test technologies are no more supported would be a great
 loss.
 So please don't remove existing selenium support so we can keep our
 test harness when migrating tapestry to 5.5, 5.6 and more .

 I added to SeleniumTestCase a way to launch a forever waiting test so
 I can play with the screens and correct them. In parallel I can run
 testng tests from eclipse that will reuse the jetty instance. It make
 me save a lot of time while finding the correct selenium xpath
 expressions. You can find the code here.
 https://gist.github.com/ddelangle/6129694

 Do you know casperjs ? It provides a javascript DSL to run tests on
 headless webkit (phantomjs) and firefox, that makes it much faster
 that with selenium and can be run on simple servers without Xserver.
 http://casperjs.org/


 Regards,

 Denis

 2013/8/1 Taha Hafeez Siddiqi tawus.tapes...@gmail.com:
  +1 for Spock and Geb.
 
  I have been using Spock and Geb for some time now. Being both in Groovy
 saves you a lot of time.
 
  One of the concerns that I have with Geb is unstable tests which seems
 to be related to WebDriver but, for some reason, are more visible with Geb.
 
  BTW Spock extensions are really easy and fun to write!.
 
 
  regarding Ulrich's point. I agree that Tapestry stack keeps changing and
 it is not easy to cope up with it. Actually, that is a great thing if you
 have time to learn. You get free examples in the clearest of codes from
 Howard!! On the flip side, if you don't have time, you lag behind and can't
 contribute much to the project. That is one reason my blog has dried out as
 I couldn't get time to experiment with Tapestry 5.4.
 
  Thankfully, we have started migrating our libraries to Tapestry 5.4. I
 am now looking into the new source and it looks like an exciting next few
 weeks.
 
  regards
  Taha
 
  On 31-Jul-2013, at 7:54 PM, Massimo Lusetti mluse...@gmail.com wrote:
 
  On Wed, Jul 31, 2013 at 4:10 PM, Ulrich Stärk u...@spielviel.de wrote:
 
  One reason I haven't contributed much in terms of code for quite some
 time
  is the ever changing
  technology stack Tapestry is built with. We have an increasingly
 complex
  stack of bleeding-edge
  tools and technologies that I simply lack the time of keeping up with.
 
  I have the feeling that this might be a turn-down for other potential
  contributors as well. I won't
  be against it but don't be surprised about continously declining
  contributor activity.
 
 
 
  One the other side I've always taken the stack of bleeding-edge tools
 and
  technologies used inside Tapestry as a reason to learn cool new stuff
 and
  ideas.
 
  BTW Spock and Geb doesn't seem so new in the market, well newer then
 TestNG
  and EasyMock yes.
 
  I can buy your point of view from a enterprise business point of view
 but
  I think we talking about a slow scrap with a deprecation cycle instead
 of
  simply throw away in the trash.
 
  --
  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: Bootstrap 3 and tapestry 5.4

[Barry Books]

I guess it depends on what many changes means. Having used Bootstrap 1,2
and 3 the I don't think the Bootstrap team worries to much about backward
compatibility. For example the grid css classes have changed every release.
I would say having to go back thru all the pages and change the grid css is
a pretty big change however I like Bootstrap and in my opinion the good
easily out weighs the bad.

What I would like from Tapestry is a stable markup output from all the
Tapestry components so I can change markup with visitors. Grid has the lean
option and I think something like min would be good. Min could output just
the markup needed with no CSS. This way the output can easily and reliably
be adapted to whatever CSS framework you like.

Currently I've had pretty good luck just dropping in new Tapestry versions
but markup changes introduce a whole new problem. Unlike api changes they
are not easy to test for automatically, the IDE does not help you find them
and end users will see them.

As far as tying Tapestry versions to Bootstrap version that the last thing
I'd like to see because it's going to keep people from upgrading. I think
it needs to be simple to use whatever Bootstrap CSS you like. In fact I'd
like Tapestry to just use WEB-INF/bootstrap if it's there. This will of
course cause problems if the markup changes which is why I think Tapestry
needs a stable markup option.



On Sat, Jul 27, 2013 at 9:10 AM, Dimitris Zenios
dimitris.zen...@gmail.comwrote:

 What ever is chosen it would be nice for someone to upgrade to a newer
 version of bootstrap without many changes.

 Regarding the switch from 5.3 to 5.4 yes that should have some difficulties
 especially if your application was overriding some tapestry css classes
 such as t-data-grid,t-zone etc etc which you weren't supposed to do.Instead
 you had to append your own class name and do modifications on that class.

 From now on though tapestry does not use class names to locate elements.It
 uses data attributes instead so most probably you should not have a problem
 upgrading to future versions of tapestry.

 As far as future version of bootstrap I also don't see a major problem
 upgrading as long as tapestry-core uses as less bootstrap java script code
 as possible and appended css class are configurable.Like grid is (
 ComponentParameterConstants.GRID_TABLE_CSS_CLASS ).

 For example tapestry-core now uses bootstrap module in two places.One in
 autocomplete mixin that uses bootstrap-typeahed and the other is the errors
 component ( I don't know why the errors component imports bootstrap module
 )

 In bootstrap 3, typeahead plugin is removed and instead you have to use
 twitter-typeahead which is not bootstrap specific.

 So if autocomplete mixin is changed to use twitter-typeahed and
 import=bootstrap is removed from alerts component there shouldn't be a
 problem regarding java script side.

 For the css part there might be a slide problem in ControlGroup mixin and
 label component from a quick look since both have the class names hard
 coded (control-label,control-group etc etc).If we can make those
 configurable also then i don't think there should be a problem upgrading to
 future bootstrap version at all.


 On Sat, Jul 27, 2013 at 4:37 PM, Bob Harner bobhar...@gmail.com wrote:

  switching this to the dev list
 
  From http://blog.getbootstrap.com/ about Bootstrap 3: With over ~1,600
  commits, ~72,000 additions/deletions, and ~300 files changed,everything
 has
  changed. The list of changes:
 https://github.com/twbs/bootstrap/pull/6342
 
  The Bootstrap version question raises a larger issue... should each
 version
  of Tapestry be tied to a certain version of Bootstrap?
 
  In my experience the biggest part of migrating an app from Tapestry 5.3
 to
  5.4 is adjusting to the massively changed styles of the built-in Tapestry
  components due to the introduction of Bootstrap. Even for apps that
 already
  use Bootstrap, there are CSS adjustments for the particular version of
  Bootstrap that Tapestry includes.
 
  I wonder if there is some mechanism that could be introduced that would
  allow for the creation of compatibility modes (or compatibility modules)
  for the CSS in the built-in components. I have no idea what that
 mechanism
  would look like, but if it existed then it could allow users to choose
  between Bootstrap 2 versus 3 versus the old non-Bootstrap styles.
 
  On Sat, Jul 27, 2013 at 8:49 AM, Barry Books trs...@gmail.com wrote:
 
   I would agree with that.  I suspect Bootstrap 3 will be done before
   Tapestry 5.5 and the markup between Bootstrap 2 and 3 changes.
  
  
   On Sat, Jul 27, 2013 at 3:15 AM, Dimitris Zenios
   dimitris.zen...@gmail.comwrote:
  
Hi everyone
   
Bootstrap 3 RC1 is released and get bootstrap page redirect to
 download
   the
new version instead of the old (2.3.2)
   
   
As a suggestion maybe it will be better to upgrade the bundled
  bootstrap
inside tapestry 5.4 to version 3

Re: Now concerned about ETags

[Barry Books]

If the goal if to have the browser cache the asset and only do a new
request when the asset changes I think the only reliable way to accomplish
this is by setting the expires header and changing the url when the asset
changes. This way the browser has no choice but to do the right thing.

What's the rational for treating module URLs differently than assets?


On Wed, Jun 5, 2013 at 4:04 AM, Massimo Lusetti mluse...@gmail.com wrote:

 On Wed, Jun 5, 2013 at 1:09 AM, Howard Lewis Ship hls...@gmail.com
 wrote:

 I believe that if we add a Cache-Control: must-revalidate to module
  content responses it should work as expected.
 


 BTW I've always had problems with cache and cache headers, anyway, at
 w3c[1] it clearly states that the cache-control header must be honored by
 all caching mechanism in the chain serving a http request but if you go at
 must-revalidate[2] it says that it must be revalidated when it becomes
 stale so it has to become stale (expires or max-age) before the cache must
 obey to that header.


 [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
 [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

 --
 Massimo Lusetti

Re: jQuery 2.x or stick with 1.x?

[Barry Books]

From the jQuery 2.0 release notes:

As promised, this version leaves behind the older Internet Explorer 6, 7,
 and 8 browsers. In return it is smaller, faster, and can be used in
 JavaScript environments where the code needed for old-IE compatibility
 often causes problems of its own. *But don’t worry, the jQuery team still
 supports the 1.x branch which does run on IE 6/7/8.* You can (and should)
 continue to use jQuery 1.9 (and the upcoming 1.10) on web sites that need
 to accommodate older browsers.


I use Tapestry to build sites for business/government that are still using
Windows XP and are therefore stuck on IE8. Bootstrap 3.X appears it will
support IE8. I can see why people would rather drop older IE support but at
this point I don't think it's practical if you want your product to be used
in a business/government environment.

So I would say if it's easy to pick (or Dmitry's suggestion) I'm OK with
that but if it you are talking about dropping IE8 support I would have to
say a *BIG* -1.

Barry




On Mon, May 27, 2013 at 12:59 AM, Kristian Marinkovic 
kristian.marinko...@gmail.com wrote:

 +1
 Am 26.05.2013 19:01 schrieb Jochen Frey joc...@jochenfrey.com:

  +1
 
  -- j
 
  On May 26, 2013, at 9:06 AM, Emmanuel DEMEY demey.emman...@gmail.com
  wrote:
 
   +1 !!!
  
  
   2013/5/26 Dimitris Zenios dimitris.zen...@gmail.com
  
   +1
  
  
   On Sun, May 26, 2013 at 6:58 PM, Howard Lewis Ship hls...@gmail.com
   wrote:
  
   What do people think about moving the embedded jQuery library up to
 the
   2.x
   version?  I would tend to favor the idea, given that anyone who truly
   cares
   can switch it back.
  
   --
   Howard M. Lewis Ship
  
   Creator of Apache Tapestry
  
   The source for Tapestry training, mentoring and support. Contact me
 to
   learn how I can get you up and productive in Tapestry fast!
  
   (971) 678-5210
   http://howardlewisship.com
  
  
  
   --
   Emmanuel DEMEY
   Ingénieur Etude et Développement
   ATOS Worldline
   +33 (0)6 47 47 42 02
   demey.emman...@gmail.com
   http://emmanueldemey.fr/
  
   Twitter : @EmmanuelDemey
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
  For additional commands, e-mail: dev-h...@tapestry.apache.org
 
 

Re: Coming soon: per-Asset checkums in URLs

[Barry Books]

After being bitten by APPLICATION_VERSION I switched to this

configuration.override(SymbolConstants.APPLICATION_VERSION,
*new*Date().getTime());


This way on my development machine I get a new version every restart and on
my production machine on every deploy.


That said I think the hash of the object in the URL and a never expires
header is the way to handle this. The only problem I can think of is assets
in style sheets. I would say the solution to that problem lookup the asset
with the hashed url and return the object with a never expires header. If
there is no hash just return the object without the header. This makes it
easy to use assets in stylesheets. If you want to solve the caching problem
just override (or declare) the style in the Layout component and use the
asset like this:


style

.navbar-fixed-top {

xheight: 64px;

 background-position: 0px 40px;

xbackground-image: url('${context:/images/top-background.jpg}');

xbackground-repeat: repeat-x;

}

/style

Re: Coming soon: per-Asset checkums in URLs

[Barry Books]

I'm not a big fan of the release in the URL  for three reasons 

1 it causes problems in development because things change but the URL does not

2 it causes all resources to become invalid with a release even if they do not 
change. The more often you release the bigger the problem

3. It complicates CDN integration because all the assets paths change every 
release

Using a hash as part of the URL 

/assets/myapp/hash/.../name solves these but makes the URL difficult to 
predict. Adding 
/assets/myapp/nocache/.../name

Makes it possible to predict the name in style sheets if needed and CSS rules 
allow this to be overridden in the layout if you want the performance increase. 
The ETag could also be used here so the nocache asset could return a not 
modified 

On Apr 9, 2013, at 9:46 AM, Ivan Khalopik ikhalo...@gmail.com wrote:

 In my opinion the best practice is to use ETag in addition to application
 version folder. So the first level of asset caching is by path, e.g.
 /assets/myapp/1.0.0/... When we deploy a new app version, this path is
 changed and browser forces new assets retrieval. If application version is
 not changed, we have the same path for assets and they are cached by
 browser until expired. But we can also reduce the traffic even if app
 version is changed or browser cache is expired. If we have the second level
 of cache using ETag. If asset checksum is changed we will return the whole
 asset content, or just 304 otherwise.
 
 So, application version folder reduces request count to those that are not
 cached for current app version, ETag reduces the rest of traffic if asset
 checksum is not changed.
 
 
 
 
 On Tue, Apr 9, 2013 at 4:39 PM, Dmitry Gusev dmitry.gu...@gmail.com wrote:
 
 Barry,
 
 no need to pass current date as application version, because if you don't
 supply any defaults then
 tapestry will generate random version for you.
 
 But this may have some limitations if you're running in a clustered
 environment.
 
 Also your clients will get new assets every time you restart your server.
 
 See this:
 
 http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3caanlktinz4ukjng-zom8t86ry-mrw7st7e9eufhkvv...@mail.gmail.com%3e
 
 
 On Tue, Apr 9, 2013 at 5:26 PM, Barry Books trs...@gmail.com wrote:
 
 After being bitten by APPLICATION_VERSION I switched to this
 
 configuration.override(SymbolConstants.APPLICATION_VERSION,
 *new*Date().getTime());
 
 
 This way on my development machine I get a new version every restart and
 on
 my production machine on every deploy.
 
 
 That said I think the hash of the object in the URL and a never expires
 header is the way to handle this. The only problem I can think of is
 assets
 in style sheets. I would say the solution to that problem lookup the
 asset
 with the hashed url and return the object with a never expires header. If
 there is no hash just return the object without the header. This makes it
 easy to use assets in stylesheets. If you want to solve the caching
 problem
 just override (or declare) the style in the Layout component and use the
 asset like this:
 
 
 style
 
 .navbar-fixed-top {
 
xheight: 64px;
 
 background-position: 0px 40px;
 
xbackground-image: url('${context:/images/top-background.jpg}');
 
xbackground-repeat: repeat-x;
 
}
 
 /style
 
 
 
 --
 Dmitry Gusev
 
 AnjLab Team
 http://anjlab.com
 
 
 
 -- 
 BR
 Ivan

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

Re: Coming soon: per-Asset checkums in URLs

[Barry Books]

I could just use the default but this way I know what it's doing. I also 
release more than I restart so that does not matter to me. Clustering would be 
a problem

On Apr 9, 2013, at 8:39 AM, Dmitry Gusev dmitry.gu...@gmail.com wrote:

 Barry,
 
 no need to pass current date as application version, because if you don't
 supply any defaults then
 tapestry will generate random version for you.
 
 But this may have some limitations if you're running in a clustered
 environment.
 
 Also your clients will get new assets every time you restart your server.
 
 See this:
 http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3caanlktinz4ukjng-zom8t86ry-mrw7st7e9eufhkvv...@mail.gmail.com%3e
 
 
 On Tue, Apr 9, 2013 at 5:26 PM, Barry Books trs...@gmail.com wrote:
 
 After being bitten by APPLICATION_VERSION I switched to this
 
 configuration.override(SymbolConstants.APPLICATION_VERSION,
 *new*Date().getTime());
 
 
 This way on my development machine I get a new version every restart and on
 my production machine on every deploy.
 
 
 That said I think the hash of the object in the URL and a never expires
 header is the way to handle this. The only problem I can think of is assets
 in style sheets. I would say the solution to that problem lookup the asset
 with the hashed url and return the object with a never expires header. If
 there is no hash just return the object without the header. This makes it
 easy to use assets in stylesheets. If you want to solve the caching problem
 just override (or declare) the style in the Layout component and use the
 asset like this:
 
 
 style
 
 .navbar-fixed-top {
 
xheight: 64px;
 
 background-position: 0px 40px;
 
xbackground-image: url('${context:/images/top-background.jpg}');
 
xbackground-repeat: repeat-x;
 
}
 
 /style
 
 
 
 -- 
 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: Coming soon: per-Asset checkums in URLs

[Barry Books]

When I tried to integrate the Amazon CDN with Tapestry the version in the URL 
was a constant problem. The other issue is the zipped vs unzipped assets. 
Tapestry uses the same URL for both but you can't do that with Amazons CDN. You 
need two files. This will also be a problem with caching  by ETag since 
compressed and uncompressed assets will have different ETags.  I think 
processing the CSS is likely to also cause CDN problems. 

GWT uses the hash in asset urls and it seems to work fine. It also used nocache 
in the URL to specify the URL is not cached. This can be useful under some 
circumstances. 

On Apr 9, 2013, at 11:37 AM, Howard Lewis Ship hls...@gmail.com wrote:

 In 5.4-alpha-3, Tapestry parsers CSS and converts url() references into
 absolute paths that include the asset checksum.
 
 There may also be the option to inline small assets directly into the
 stylesheet.
 
 
 On Tue, Apr 9, 2013 at 6:26 AM, Barry Books trs...@gmail.com wrote:
 
 After being bitten by APPLICATION_VERSION I switched to this
 
 configuration.override(SymbolConstants.APPLICATION_VERSION,
 *new*Date().getTime());
 
 
 This way on my development machine I get a new version every restart and on
 my production machine on every deploy.
 
 
 That said I think the hash of the object in the URL and a never expires
 header is the way to handle this. The only problem I can think of is assets
 in style sheets. I would say the solution to that problem lookup the asset
 with the hashed url and return the object with a never expires header. If
 there is no hash just return the object without the header. This makes it
 easy to use assets in stylesheets. If you want to solve the caching problem
 just override (or declare) the style in the Layout component and use the
 asset like this:
 
 
 style
 
 .navbar-fixed-top {
 
xheight: 64px;
 
 background-position: 0px 40px;
 
xbackground-image: url('${context:/images/top-background.jpg}');
 
xbackground-repeat: repeat-x;
 
}
 
 /style
 
 
 
 -- 
 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

Questions about making Parameters defaulted to Symbols writable (includes solution)

[Barry Books]

There have been several discussions on the user list about the failure
@BindParameter to override Parameters that have defaults set to
Symbols. The symbol bind prefix is readonly so attempting to override
the parameter value results in a read only exception. I've also run
into this issue and decided to try and fix it. After thinking about it
the fix seems easy enough and the following code works. The question
is why.

public class MySymbolBindingFactory implements BindingFactory {

private final SymbolSource symbolSource;
private final Logger logger;

   public MySymbolBindingFactory(SymbolSource symbolSource, Logger 
logger)
   {
   this.symbolSource = symbolSource;
   this.logger = logger;
   }

   public Binding newBinding(String description,
ComponentResources container,
   ComponentResources component, String expression,
Location location)
   {

   String value = symbolSource.valueForSymbol(expression);
   return new SymbolBinding(location, description, value);
   }

   public class SymbolBinding implements Binding {
   private Object value;

   public SymbolBinding(Location location, String description,
String value) {
   this.value = value;
   }

@Override
public T extends Annotation T getAnnotation(ClassT 
arg0) {
return null;
}

@Override
public Object get() {
return value;
}

@Override
public Class getBindingType() {
return value.getClass();
}

@Override
public boolean isInvariant() {
return false;
}

@Override
public void set(Object value) {
//just ignore this
}

   }
}

The original symbol binding throws an error in the set method. This
one just ignores it. I've done some limited testing and this appears
to work but the questions are why does it work, will it continuing to
work and what are the drawbacks.

From what I can tell the actual value for the parameter is not stored
in the binding but in a per request map behind a proxy. When the
component is initialized by a request the value in the map is set to
the default (a symbol binding) if no value is provided. Using
@BindParamter attaches to the proxy and calling set in the mixin calls
set on the map and the symbol. Reading the parameter value results in
a get from the map so it does not matter what the symbol value is.

What if any are the drawbacks to this? One is the binding is no longer
invariant. I suppose this could have performance implications since
the value is no longer cacheable. I'm not sure that's really a problem
and certainly no worse that just removing the default. The second I'm
less sure about. Much of the magic behind Parameters is undocumented
and I'm guessing it's possible some change could break this.

I think if for some reason the actual value was stored in the binding
object it would be possible to use the request object to store the
value but at this point that seems like an unnecessary complication.

Any comments from someone that really understands this subject would
be appreciated.

Thanks
Barry

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

Re: Questions about making Parameters defaulted to Symbols writable (includes solution)

[Barry Books]

I agree it seems like the limitation was not intended and your suggestion is 
best long term. Until then this part seemed the easiest to override. 
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org

Re: Before I file a JIRA against SupportsInformalParameters

[Barry Books]

I noticed Tapestry has a mixin called RenderInformals. I tried to use
it instead of the one I wrote and even though the code is the same it
did not work. I have a suspicion that it's really the mixin that sorts
first by name gets the informal parameters.

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

Re: Before I file a JIRA against SupportsInformalParameters

[Barry Books]

I was able to fix my specific problem but when I tried to do the same
thing on my test case the results are different.

I fixed my problem by creating another mixin with @MixinAfter that
renders informal parameters. My theory was that the first mixin to
render informal parameters gets the ones in the default namespace and
renders them on the current element.

In my specific case this seems to be true but I was not able to
confirm that with my test case.

Does anyone know what the real rule is (or should be) when the
component and mixins both support informal parameters? I'm pretty sure
the namespaced ones always go to a specific mixin but I still don't
understand the rule for the default namespace informal parameters
however I'm pretty sure it's not what the documentation says.

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

Before I file a JIRA against SupportsInformalParameters

[Barry Books]

I posted a question about @SupportsInformalParameters to the user list
yesterday but got no useful response. After writing some test cases
its clear to me @SupportsInformalParamters and mixins do not do what
the documentation says. My question is which is wrong the code or the
document?

From the behavior I'd say the documentation is correct and the code is wrong.


I created a fresh project with 5.3.1 and in Index.tml I have this:

t:any type=greeting t:mixins=IP2,IP ip2.foo=bar2
ip.foo=bar${message:greeting}/t:any

I also created two mixins

@SupportsInformalParameters
public class IP2 {
@Inject
private ComponentResources resources;

@BeginRender
void beginRender(MarkupWriter writer) {
writer.element(IP2);
resources.renderInformalParameters(writer);

}

@AfterRender
void afterRender(MarkupWriter writer) {
writer.end();
}
}

@SupportsInformalParameters
public class IP {

@Inject
private ComponentResources resources;

@BeginRender
void beginRender(MarkupWriter writer) {
writer.element(IP);
resources.renderInformalParameters(writer);

}

@AfterRender
void afterRender(MarkupWriter writer) {
writer.end();
}
}

The output is this

ip foo=bar type=greeting
ip2 foo=bar2
divWelcome to Tapestry 5!  We hope that this project template will
get you going in style./div
/ip2
/ip

The document says this

If the component and a mixin both define a parameter with the same
name, then the component wins: the component's parameter will be
bound, and the mixin's parameter will be unbound.

I would say in this case type=greeting belongs on the div node
because the document says the component wins in this case. If not then
where should it be and what should the documentation say? If I reverse
the order of the mixins type=greeting still ends up on the ip node.

So are the docs wrong, is the code wrong or am I just confused?

Thanks
Barry

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

Proposal for an Application Defaults solution

[Barry Books]

I've been think about Howard's email a couple of days ago and it
occurred to me that while Tapestry provides a very good set of tools
for solving common problems encountered doing web development it does
not actually solve them. This is not a complaint and in fact I think
it's the right approach for a framework, but I think in order to build
a community around Tapestry these common problems need a common
solution. The great thing about Tapestry and IOC is you can build a
common solution and then either replace or extend it.

During this same time I noticed a couple of email about how to
implement defaults. Tapestry provides a way to do this buy it's
completely static. That's a good start but it does not really solve
the application development problem.

Problem Definition:
There needs to be a way to have defaults for various values used by an
application. Defaults should be provided by modules. It should be
possible to override these defaults via the Tapestry IOC applications
default mechanism. And finally it should be possible to override this
defaults and runtime. The runtime mechanism may be provided by the
application so defaults could for example be stored in a database.
Lastly the override mechanism should allow overriding the defaults
based on the context.

While this sounds like a pretty tall order thanks to the tools
provided by Tapestry it's actually pretty easy.

The Solution:
There are a few parts to the solution.

1. Implement a binding prefix called default which can retrieve the
default for a key
2. Provide a way to contribute module defaults
3. Provide a service that can retrieve defaults for a binding key

Creating a binding prefix is easy:

https://github.com/trsvax/tapestry-trsvax/blob/master/src/main/java/com/trsvax/tapestry/misc/services/DefaultBinding.java

Contributing binding defaults is even easier:

public final static String id = MiscModule;

@Contribute(Defaults.class)
public static void contributeDefautls(MappedConfigurationString,
StaticDefaults configuration) {
configuration.add(id,new MyDefaults());
}

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

Re: Proposal for an Application Defaults solution

[Barry Books]

Sorry about the 2 part email.

The service to fetch the defaults is also pretty simple

https://github.com/trsvax/tapestry-trsvax/blob/master/src/test/java/com/trsvax/tapestry/misc/services/DefaultsImpl.java

So with these 3 parts you can do things like:

In a comonent
@Parameter(MyDefaults.defaultKey)
private String value;

In a tml file
   ${default:MiscModule:defaultKey:abc}

In your appModule
public void
contributeApplicationDefaults(MappedConfigurationString, String
configuration)
{
  configuration.add(MyDefaults.defaultKey, WackyCollaborator);
}

Since the Default service has access to the Location and the Component
you can override defaults based on the page or the component complete
id. Lastly since you can provide your own Default service you can
drive the final default value from your database (or whatever).

If all the modules use something like this it would allow applications
to have fine grain control over the defaults for services and
components. For example I could default the grid pager rows to 50 on
one page and 10 one another. If I needed to I could control the zone
refresh color and style by user.

Comments?

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

Re: Proposal for an Application Defaults solution

[Barry Books]

I can see the overlap but I think the Metadata service is only for
pages/components and I was looking for a general purpose application
default solution. For example you could store the email address for
the site admin in here. I don't think the MetaData service would be
appropriate for that.

Perhaps the other bit I was not clear about is the standardized way
the keys are stored. For example the defaults for a module are stored
in this format.

public class MyDefaults extends AbstractStaticDefaults implements
StaticDefaults  {
 public final static String defaultKey = default: + MiscModule.id +
:defaultKey:abc;
}

This allows the default service to look them up by module id, provides
a namespace and the default value is obvious.

I can see the two working together. The real problem I trying to solve
is a common solution that is easily used by module builders as well as
application builders that allows defaults to be stored in an
application specific way (most likely a database). Currently the
pieces are there what's lacking I think is a convention for doing it.
Without the convention everyone solves the problem in a different way
and the modules/applications cannot interoperate easily.

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

Re: Feedback from Tapestry users

[Barry Books]

MAKE IT EASIER TO DONATE COMPONENTS  CODE

I think this is a great idea but I don't think it needs to be that
complicated.  To me the problem is there is no central repository for
module jars so I end up adding a bunch of repositories to my pom file.
All that's needed is a way to submit a repository url to a build
process that just creates jars for each project. Then you just add
that repository to your pom file and you are good to go.  It could be
as simple as a Jenkins install that just builds jars from svn or git
and places the jars in a common location. You could have both
snapshots and releases. The build process could also build a
documentation site that describes all the modules so you have one
place to find everything.

MOVE TOWARDS GREATER CLIENT-SIDE FOCUS

There are really two paths here, progressive enhancement and something
more like GWT.

When I'm building public websites I usually pick progressive
enhancement. It took me a while but I finally figured out mixins are
the way to do this. I could never get the hang of Prototype but with
JQuery it is pretty easy to build sites this way. The only real
problem is you can't pass a javascript function back thru an AJAX
request because JSON does not allow functions. The second problem is
it seems pretty easy to end up with a big mess after doing a bunch of
zone updates to the same page but that's just the nature of doing
things this way. Since I've heading down this path I'd say Tapestry is
one of the best frameworks for building this kind of site.

For internal application type sites I've always used GWT with
Tapestry. It's nice using Java on both sides and with Eclipse you can
debug both the client and the server at the same time. The problem is
it's a bit difficult to integrate the two and I've never be completely
happy with what I've come up with. My other complaint about GWT is the
widgets are not very polished and it takes a lot of work to get them
to look nice.

I think the challenge here is deciding what Tapestry wants to be. I
can understand wanting to be JavaScript framework agnostic but I think
this causes two problems.

1. You end up with the lowest common denominator of functionality

2. You have to port every component to every framework or run mixed frameworks

The problem with picking one is you limit the audience to developers
that like Tapestry and whatever JavaScript framework you pick.

Not an easy choice

 IS TAPESTRY JUST TOO WIERD/ESOTERIC/ENLIGHTENED FOR SOME/MANY JAVA DEVELOPERS?

With Tapestry 5 I think it's finally approaching simple things are
simple, difficult things are only slightly harder. Personally I think
implementing the shared component library would go a long way toward
solving this complaint because it would provide examples of how to
solve problems and working code to solve them. The Tapestry-Hibernate
module is great because it just works and I don't have to figure out
how to integrate hibernate with Tapestry. It has some shortcomings but
it's simple and it works for most use cases. I suspect a big part of
the learning curve is the lack of Tapestry-Auth. Almost every app
needs something like that and implementing one that really works is
difficult so the first thing that happens is you get stuck and give
up.

Some suggestions:

1. It would be great if BeanEdit/PageActivation etc could just work
with an Interface because I think this would make building libraries
easier. I could have a User Interface and implement it in Hibernate or
JPA. Then it could also implement what's needed by a Tapestry-Auth
module and they could all work together. Currently you can't do this
easily. Hopefully this would lead to a set of modules that could
interoperate and give developers a big head start when building apps.
A long time ago I used ACS ( now openacs.org ). It was helpful to be
able to just pickup a forum module rather than implementing one. Since
they shared common interfaces the forum module would just work with
the permission module.

2. I know I created a heated discussion with my desire for a Tapestry
object I could inject and have access to multiple services but I still
think it would be useful. It would be nice if you bind an entire
module with something like binder.bindModule(module.class) and then in
your page just say

@Inject
private Module module;

I think this fits nicely with the first idea and I think it would make
things easier for new comers because it clearly defines the API for a
particular module.

Thanks
Barry

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

Re: tapestry-hibernate handling of transients instances ValueEncoder

[Barry Books]

I gave up trying to use the same page for create and edit because it
takes more code to use one page than two. My thought would be to do
this

@PageActivationContext(create=true)
private MyEntity myEntity;

This would create the object if you do not pass one in. Then you don't
have any backward compatibility problems and you don't have to have
any code in the activation context.

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

Would it be possible (or desirable) to add a TapestryCoreServices Interface for 5.3 beta?

[Barry Books]

I just spent about 30 minutes looking for a way to get the
ServletContext. I knew it was available but I could not remember which
service provides it. So while I was searching I was thinking it might
be nice to have a set of Interfaces/Services that define all the
public services. For Tapestry core that might be TapestryCoreServices
and TapestryCoreRequestServices to differentiate between global
services and ones that are request specific. This would help with a
few things. One I could just say

@Inject
private TapestryCoreServices coreServices;

then just
coreServices.getApplicationGlobals().getServletContext()

This would cut down on the number of fields I need to create just to
call a few methods. Secondly I think would make it more obvious which
services are public and which are internal. I realize the package does
that but who looks at the package name? Lastly I think it would be
easier for new comers to learn what services are available. The last
one is not a complaint about the documentation but more a comment
about how useful code completion can be.

So in short the Interface would give you a starting point to all the
services available from a module. The naming convention could continue
such as TapestryIOCServices etc.

Thanks
Barry

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

Re: ValueChanged event from RadioGroup and Checkbox

[Barry Books]

The zone parameter is easy to use but not very flexible. I wrote a
bind mixin for jQuery that hooks events to pretty much anything. I
suspect you could do the same thing in Prototype. Bind is subclassed
to the event you want to capture so multiple events can be attached to
a single element. Here is an example of a component that hooks a
slider to a select using SlideChange and Change events. The example
also uses the selector binding I wrote.

t:any element=div t:type=any t:id=slider
t:mixins=jquery/ui/slider,SlideChange
slidechange.event=${event}
slidechange.zone=${zone}
slidechange.callback=function (event,ui,url) {url.addContext(
${selector:size}.val() )}
slider.script='{min:1, max: 5, value: ${selector:size}[ 0 
].selectedIndex + 1,
slide: function( event, ui, url ) {
${selector:size}[ 0 ].selectedIndex = ui.value 
- 1;
}
}' 
/t:any
t:select t:id=size
model=literal:GreetingPanel,Small,Medium,Large,Jumbo
t:mixins=change
change.callback=function(event,ui,url) {
${selector:slider}.slider( 'value',
${selector:this}[0].selectedIndex + 1);
} /

The SlideChange event causes a zone update and the value of the slider
is passed to Tapestry. A change event on the select updates the slider
which in turn causes a SlideChange and zone update. The example above
is certainly more complicated than a simple zone update but I think
the code is pretty readable.

So I would say you need both. A simple zone parameter to do simple
things and a more versatile  event manager when you need more control.

The code for bind is here

https://github.com/trsvax/tapestry5-jquery/blob/master/src/main/java/org/got5/tapestry5/jquery/mixins/Bind.java

Barry

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