Re: Introducing Croquet: Combining Wicket, Jetty, Hibernate, and Guice

2014-04-15 Thread Chris Snyder
I agree that JPA can be clunky. I have found the CriteriaBuilder way of
building queries to be manageable (if a bit verbose). So far, I’ve used JQL
queries (defined in @NamedQuery annotations) for the queries that have a
well-defined structure, and CriteriaBuilder for the more complex cases
(such as filtering by a user-defined set of parameters). My use cases have
been relatively simple, though.

-Chris


On Tue, Apr 15, 2014 at 8:49 AM, William Speirs wspe...@apache.org wrote:

 I hadn't heard of it. There are a few ORMs out there. I've looked at this
 library as well: http://jdbi.org/ However, that's a bit too much SQL
 writing for just the basic objects for me. Though it is a GREAT setup to
 make unit testing REALLY easy.

 I just find the JPA API so clumsy, especially when building dynamic
 queries. Even Hibernate's native interface is MUCH better than JPA.

 Bill-


 On Tue, Apr 15, 2014 at 3:26 AM, Martin Grigorov mgrigo...@apache.org
 wrote:

  what do you think about JOOQ ?
 
 
 
 http://www.petrikainulainen.net/programming/jooq/using-jooq-with-spring-crud/
 
  Martin Grigorov
  Wicket Training and Consulting
 
 
  On Tue, Apr 15, 2014 at 6:00 AM, William Speirs wspe...@apache.org
  wrote:
 
   Off-topic a bit... on the JPA front, I'm still relatively new and
 finding
   it not as useful as I would have hoped. Beyond VERY simple
   read-by-primary-key and update/create/delete, anything else seems
  tedious.
   I'm having to learn the JPA query language (yes, you can use SQL but
 then
   you lose generics/typing). I'm highly considering updating another one
 of
   my projects SOP4J-DBUTILS (https://github.com/wspeirs/sop4j-dbutils)
 to
   handle JPA annotations for the basic CRUD operations, then just making
 it
   slightly easier to use complex where clauses to populate POJOs.
  
   Thoughts?
  
   Bill-
  
   P.S. We should probably take this off the Wicket list if folks want to
   continue discussing...
  
  
  
   On Mon, Apr 14, 2014 at 9:03 AM, Chris Snyder 
 chris.sny...@biologos.org
   wrote:
  
Thanks for the reply - no worries on the delay.
   
In my case, I'm using EclipseLink. I originally was using Hibernate,
  but
switched after encountering a known bug in Hibernate (the specifics
 of
which I no longer recall). Since I was sticking to using the pure JPA
   API,
it was a quick drop-in replacement. Recently, however, I have used a
   couple
of EclipseLink-specific features, so it wouldn't be as quick to
 switch
   back
(assuming that the bug in Hibernate has been fixed).
   
This certainly wouldn't stop me from checking out Croquet - if I end
 up
adapting it to use EclipseLink, I'll be sure to share my changes.
   
Best,
Chris
   
   
On Mon, Apr 14, 2014 at 8:44 AM, Bill Speirs bill.spe...@gmail.com
wrote:
   
 Chris, sorry for not responding more quickly... was traveling back
  from
 ApacheCon NA.

 Honestly, it would be non-trivial to drop in a replacement to
   Hibernate.
 The JpaPersistService (http://goo.gl/FeI6xU) handles the
  configuration
 coming from persistence.xml and has nothing Hibernate specific. The
problem
 is the CroquetPersistService, DataSourceHibernateModule, and
 EntityManagerProxyFactory classes.

 What JPA provider would you rather use? I've never used anything
 but
 Hibernate, and never had issues with it... just curious why you'd
  like
   to
 use something else.

 Also, patches/pull requests are always happily accepted :-)

 Thanks for checking it out...

 Bill-


 On Wed, Apr 9, 2014 at 1:05 PM, Chris Snyder 
   chris.sny...@biologos.org
 wrote:

  Looks like awesome work - very clean page design and excellent
  documentation, and I'm sure that the quality extends to the code
 as
well.
  I'll definitely be looking into this for my next project, if not
porting
  some of my current ones.
 
  When using Croquet, how easy would it be to drop in a different
 JPA
  implementation in place of Hibernate?
 
  Best,
  Chris
 
 
  On Wed, Apr 9, 2014 at 12:51 PM, William Speirs 
  wspe...@apache.org
  wrote:
 
   I gave a talk at ApacheCon NA yesterday on Croquet. It is a
combination
  of
   Wicket, Jetty, Hibernate, and Guice to make it super-easy to
  start
  writing
   Wicket code almost immediately, instead of spending time
   configuring
   everything.
  
   Slides:
  
  
 

   
  
 
 https://docs.google.com/presentation/d/1m3jdbpYoSBOCPz8Wes9mPvhf8TLp_3dndj_gW08iFL8/
   Code: https://github.com/metrink/croquet
   Docs: http://croquet.metrink.com
  
   Thanks...
  
   Bill-
  
 

   
   
   
--
Chris Snyder
Web Developer, BioLogos
616.328.5218 x203
biologos.org
   
  
 



Re: Introducing Croquet: Combining Wicket, Jetty, Hibernate, and Guice

2014-04-14 Thread Chris Snyder
Thanks for the reply - no worries on the delay.

In my case, I'm using EclipseLink. I originally was using Hibernate, but
switched after encountering a known bug in Hibernate (the specifics of
which I no longer recall). Since I was sticking to using the pure JPA API,
it was a quick drop-in replacement. Recently, however, I have used a couple
of EclipseLink-specific features, so it wouldn't be as quick to switch back
(assuming that the bug in Hibernate has been fixed).

This certainly wouldn't stop me from checking out Croquet - if I end up
adapting it to use EclipseLink, I'll be sure to share my changes.

Best,
Chris


On Mon, Apr 14, 2014 at 8:44 AM, Bill Speirs bill.spe...@gmail.com wrote:

 Chris, sorry for not responding more quickly... was traveling back from
 ApacheCon NA.

 Honestly, it would be non-trivial to drop in a replacement to Hibernate.
 The JpaPersistService (http://goo.gl/FeI6xU) handles the configuration
 coming from persistence.xml and has nothing Hibernate specific. The problem
 is the CroquetPersistService, DataSourceHibernateModule, and
 EntityManagerProxyFactory classes.

 What JPA provider would you rather use? I've never used anything but
 Hibernate, and never had issues with it... just curious why you'd like to
 use something else.

 Also, patches/pull requests are always happily accepted :-)

 Thanks for checking it out...

 Bill-


 On Wed, Apr 9, 2014 at 1:05 PM, Chris Snyder chris.sny...@biologos.org
 wrote:

  Looks like awesome work - very clean page design and excellent
  documentation, and I'm sure that the quality extends to the code as well.
  I'll definitely be looking into this for my next project, if not porting
  some of my current ones.
 
  When using Croquet, how easy would it be to drop in a different JPA
  implementation in place of Hibernate?
 
  Best,
  Chris
 
 
  On Wed, Apr 9, 2014 at 12:51 PM, William Speirs wspe...@apache.org
  wrote:
 
   I gave a talk at ApacheCon NA yesterday on Croquet. It is a combination
  of
   Wicket, Jetty, Hibernate, and Guice to make it super-easy to start
  writing
   Wicket code almost immediately, instead of spending time configuring
   everything.
  
   Slides:
  
  
 
 https://docs.google.com/presentation/d/1m3jdbpYoSBOCPz8Wes9mPvhf8TLp_3dndj_gW08iFL8/
   Code: https://github.com/metrink/croquet
   Docs: http://croquet.metrink.com
  
   Thanks...
  
   Bill-
  
 




-- 
Chris Snyder
Web Developer, BioLogos
616.328.5218 x203
biologos.org


Re: Introducing Croquet: Combining Wicket, Jetty, Hibernate, and Guice

2014-04-09 Thread Chris Snyder
Looks like awesome work - very clean page design and excellent
documentation, and I'm sure that the quality extends to the code as well.
I'll definitely be looking into this for my next project, if not porting
some of my current ones.

When using Croquet, how easy would it be to drop in a different JPA
implementation in place of Hibernate?

Best,
Chris


On Wed, Apr 9, 2014 at 12:51 PM, William Speirs wspe...@apache.org wrote:

 I gave a talk at ApacheCon NA yesterday on Croquet. It is a combination of
 Wicket, Jetty, Hibernate, and Guice to make it super-easy to start writing
 Wicket code almost immediately, instead of spending time configuring
 everything.

 Slides:

 https://docs.google.com/presentation/d/1m3jdbpYoSBOCPz8Wes9mPvhf8TLp_3dndj_gW08iFL8/
 Code: https://github.com/metrink/croquet
 Docs: http://croquet.metrink.com

 Thanks...

 Bill-



Re: The wicket way of getting application base URL

2014-03-13 Thread Chris Snyder
I think that such a configuration option is likely your only choice, and is
something I often see in other webapps. The only other option I can think
of would be if the proxy was passing a header with the original requested
URL. However, I don't see such functionality in mod_proxy (at least from a
quick skim of its documentation).

I can imagine a hacky way of using Javascript to pass it in. I'm only
mentioning it to dissuade you from considering it (if you were), as it
would be a huge security risk: Someone could send incorrect data to the
server, causing it to send out the wrong URLs. That would make for an
effective phishing campaign - emails from a legitimate source with links to
the cracker's server.

Best,
Chris


On Thu, Mar 13, 2014 at 9:22 AM, jchappelle jchappe...@4redi.com wrote:

 We just use a configuration property in our application that is stored in
 our
 properties database table. So our solution really doesn't involve wicket
 at all.

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/The-wicket-way-of-getting-application-base-URL-tp4664925p4664938.html
 Sent from the Users forum mailing list archive at Nabble.com.

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




-- 
Chris Snyder
Web Developer, BioLogos
biologos.org


Best practice for updating JPA object without persisting changes

2014-03-05 Thread Chris Snyder
I'm dealing with an issue that I'm sure has been solved by many people on
this list, but I'm struggling to ascertain the best way to solve it.

I'm working on implementing in-place-edit functionality for some of our
site content. The content is stored in a database and mapped via JPA. The
edit form has the JPA entity as the backing model object.

One of the features I'm implementing is the ability to preview what's been
entered in the form without the updates being committed to the database
(until the user explicitly clicks on the Save button). I can think of a
few ways to accomplish this:

1. Rollback the transaction when not saving - This would require me to
manage the transaction manually (right now, they're being managed
automatically by Guice's PersistFilter).

2. Detach the object from the persistence context, merge it to save - This
seems like the most elegant solution, but I can see how there could be
issues (not intractable) with lazy loading.

3. Prevent the form from updating the model until save - This would break
my preview panel, and seems to be contrary to how forms normally behave.

4. Copy the data into a non-managed DTO, copying it back to the JPA object
on save - Would require a lot of clone/copy code.

This seems like such a common problem to solve - I think my relative
unfamiliarity with JPA is the main stumbling block here. How have others
implemented it? Is there a best-practice pattern that my Googling didn't
discover?

Thanks in advance for the help. I hope that it isn't too off-topic since it
is mainly JPA-related.

Best,
Chris


Re: Best practice for updating JPA object without persisting changes

2014-03-05 Thread Chris Snyder
Hi Patrick,

Thanks for the response.

does the Guice's PersistFilter really automatically find and re-attach
 the backed object in the request while leaving the in-place-edit situation?


Guice doesn't do anything with whether the objects are attached - I'm
simply never detaching them (unless I implement option #2), so any changes
made to the object are automatically persisted by the JPA engine. Guice's
role here is with transactions - the PersistFilter starts a transaction at
the beginning of the request, and commits it at the end.

Thanks,
Chris


On Wed, Mar 5, 2014 at 8:29 AM, Patrick Davids patrick.dav...@nubologic.com
 wrote:

 Hi Chris,

 I thought... as long as nothing/nobody finds and re-attach the backed
 object, your changes are naturally temporary and only stored on page
 cache.

 I would expect, it should already work out-of-the-box... But I did not
 work with Guice's PersistFilter, yet. May I miss something...

 kind regards
 Patrick

 Am 05.03.2014 12:47, schrieb Chris Snyder:
  I'm dealing with an issue that I'm sure has been solved by many people on
  this list, but I'm struggling to ascertain the best way to solve it.
 
  I'm working on implementing in-place-edit functionality for some of our
  site content. The content is stored in a database and mapped via JPA. The
  edit form has the JPA entity as the backing model object.
 
  One of the features I'm implementing is the ability to preview what's
 been
  entered in the form without the updates being committed to the database
  (until the user explicitly clicks on the Save button). I can think of a
  few ways to accomplish this:
 
  1. Rollback the transaction when not saving - This would require me to
  manage the transaction manually (right now, they're being managed
  automatically by Guice's PersistFilter).
 
  2. Detach the object from the persistence context, merge it to save -
 This
  seems like the most elegant solution, but I can see how there could be
  issues (not intractable) with lazy loading.
 
  3. Prevent the form from updating the model until save - This would break
  my preview panel, and seems to be contrary to how forms normally behave.
 
  4. Copy the data into a non-managed DTO, copying it back to the JPA
 object
  on save - Would require a lot of clone/copy code.
 
  This seems like such a common problem to solve - I think my relative
  unfamiliarity with JPA is the main stumbling block here. How have others
  implemented it? Is there a best-practice pattern that my Googling didn't
  discover?
 
  Thanks in advance for the help. I hope that it isn't too off-topic since
 it
  is mainly JPA-related.
 
  Best,
  Chris
 



Re: Best practice for updating JPA object without persisting changes

2014-03-05 Thread Chris Snyder
Hi Haiko,

Thanks for the response. You raise some good points - it certainly would be
cleaner and easier to understand. It also could be better for my layout,
given the way I've organized the code: The data layer is abstracted behind
a service API, so we could plug in a different storage engine (Cassandra
instead of JPA, for example) without needing to modify the other layers.
The editor code currently has no knowledge of JPA, so I'd have to expose
some of the business layer to implement either of my first two options.

Do you use any tools to make the copying easier, or do you code it by hand?

Thanks,
Chris

On Wed, Mar 5, 2014 at 8:07 AM, ha...@dds.nl wrote:

 Hi Chris,

 I would go for option 4. This is how I implement such cases. It has an
 explicit distinction between states 'previewMode' and 'commited Mode'.
 Looks like more coding, but actually is clear about distinction between
 preview and saved. And that would help the programmer that picks this code
 up a half year from now.

 My 2 cents.

 Best,

 Haiko

 Chris Snyder chris.sny...@biologos.org schreef:


  I'm dealing with an issue that I'm sure has been solved by many people on
 this list, but I'm struggling to ascertain the best way to solve it.

 I'm working on implementing in-place-edit functionality for some of our
 site content. The content is stored in a database and mapped via JPA. The
 edit form has the JPA entity as the backing model object.

 One of the features I'm implementing is the ability to preview what's been
 entered in the form without the updates being committed to the database
 (until the user explicitly clicks on the Save button). I can think of a
 few ways to accomplish this:

 1. Rollback the transaction when not saving - This would require me to
 manage the transaction manually (right now, they're being managed
 automatically by Guice's PersistFilter).

 2. Detach the object from the persistence context, merge it to save - This
 seems like the most elegant solution, but I can see how there could be
 issues (not intractable) with lazy loading.

 3. Prevent the form from updating the model until save - This would break
 my preview panel, and seems to be contrary to how forms normally behave.

 4. Copy the data into a non-managed DTO, copying it back to the JPA object
 on save - Would require a lot of clone/copy code.

 This seems like such a common problem to solve - I think my relative
 unfamiliarity with JPA is the main stumbling block here. How have others
 implemented it? Is there a best-practice pattern that my Googling didn't
 discover?

 Thanks in advance for the help. I hope that it isn't too off-topic since
 it
 is mainly JPA-related.

 Best,
 Chris






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




Re: Best practice for updating JPA object without persisting changes

2014-03-05 Thread Chris Snyder
Thanks, Igor - that's very helpful. Not sure how I missed that article
while I was searching.

It would be a bit tricky to implement in my situation (as I described in
another response, the JPA implementation of the data storage is abstracted
behind a service API), but I could make it work - perhaps by adding detach
and merge methods to the API; that would perhaps expose a little too much
of the implementation, but I think that other (hypothetical)
implementations could also need to expose similar functionality.

Of course, I might be over-engineering this whole abstraction anyways. I
have no intention of implementing a non-JPA version - perhaps I should
embrace a hard dependency on JPA and simplify everything. JPA is itself an
abstraction layer, after all...

Thanks,
Chris


On Wed, Mar 5, 2014 at 11:44 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 have a look here:


 https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/

 -igor

 On Wed, Mar 5, 2014 at 3:47 AM, Chris Snyder chris.sny...@biologos.org
 wrote:
  I'm dealing with an issue that I'm sure has been solved by many people on
  this list, but I'm struggling to ascertain the best way to solve it.
 
  I'm working on implementing in-place-edit functionality for some of our
  site content. The content is stored in a database and mapped via JPA. The
  edit form has the JPA entity as the backing model object.
 
  One of the features I'm implementing is the ability to preview what's
 been
  entered in the form without the updates being committed to the database
  (until the user explicitly clicks on the Save button). I can think of a
  few ways to accomplish this:
 
  1. Rollback the transaction when not saving - This would require me to
  manage the transaction manually (right now, they're being managed
  automatically by Guice's PersistFilter).
 
  2. Detach the object from the persistence context, merge it to save -
 This
  seems like the most elegant solution, but I can see how there could be
  issues (not intractable) with lazy loading.
 
  3. Prevent the form from updating the model until save - This would break
  my preview panel, and seems to be contrary to how forms normally behave.
 
  4. Copy the data into a non-managed DTO, copying it back to the JPA
 object
  on save - Would require a lot of clone/copy code.
 
  This seems like such a common problem to solve - I think my relative
  unfamiliarity with JPA is the main stumbling block here. How have others
  implemented it? Is there a best-practice pattern that my Googling didn't
  discover?
 
  Thanks in advance for the help. I hope that it isn't too off-topic since
 it
  is mainly JPA-related.
 
  Best,
  Chris

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




-- 
Chris Snyder
Web Developer, BioLogos
616.328.5218 x203
biologos.org


Re: Show textfield as plaintext when disabled?

2014-03-03 Thread Chris Snyder
One potential issue: Depending on where you're using the technique, it
could lead to problems. For instance, if you are implementing in-place-edit
functionality on a public-facing page, having a lot of your content in
input/ tags could make the content invisible to search engines (I'm just
guessing here - it would make sense for search engines to ignore form
content, but I don't know if this is true). Even if search engines aren't a
concern, it's contrary to semantic HTML, and could lead to problems for
non-graphical browsers.

Nevertheless, it's easy, and certainly acceptable for many situations.
Still, I stand by my initial cludgy assertion. :-)

-Chris


On Mon, Mar 3, 2014 at 4:04 AM, Stijn de Witt 
stijn.dew...@planonsoftware.com wrote:

 I wouldn't call it cludgy... 'pragmatic' is the word that comes to mind  :)

 Big advantage of styling the input as regular text instead of completely
 replacing the HTML element is that all other behavior remains as expected.
 The field is still submitted with the form etc.

 -Stijn


 -Original Message-
 From: Chris Snyder [mailto:chris.sny...@biologos.org]
 Sent: zaterdag 1 maart 2014 17:54
 To: Wicket users mailing list mailing list
 Subject: Re: Show textfield as plaintext when disabled?

 I also ended up going the panel route for this.

 An alternative - perhaps a bit cludgy - would be to style the input fields
 as plain text using CSS (remove the border  outline, alter the padding,
 etc.).

 -Chris

 On Sat, Mar 1, 2014 at 6:35 AM, Andrea Del Bene an.delb...@gmail.com
 wrote:

  Hi, l've tried to do a similar thing a couple of months ago but it was
  very tricky and l ended up using a panel with two components (text
  field and a label).
  You can use methods oncomponenttag and onxomponenttagbody to
  dynamically change the tag and the body depending on component status
 (view or edit)...
  Good luck :).
  On Feb 28, 2014 8:34 PM, Entropy blmulholl...@gmail.com wrote:
 
   Is there a way to have my textfield show as plain text when in a
   readonly mode rather than as a disabled textbox?
  
   Backup question: I can imagine making a panel to do this...having a
   textfield and label and hiding whichever I didn't want, but I would
   want
  my
   panel to bind to a textbox in the parent page and replace that tag
   (otherwise I would have two textboxes, right).  How would I go about
  that?
  
   --
   View this message in context:
  
  http://apache-wicket.1842946.n4.nabble.com/Show-textfield-as-plaintext
  -when-disabled-tp4664723.html
   Sent from the Users forum mailing list archive at Nabble.com.
  
   
   - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
 



Re: Show textfield as plaintext when disabled?

2014-03-01 Thread Chris Snyder
I also ended up going the panel route for this.

An alternative - perhaps a bit cludgy - would be to style the input fields
as plain text using CSS (remove the border  outline, alter the padding,
etc.).

-Chris

On Sat, Mar 1, 2014 at 6:35 AM, Andrea Del Bene an.delb...@gmail.comwrote:

 Hi, l've tried to do a similar thing a couple of months ago but it was very
 tricky and l ended up using a panel with two components (text field and a
 label).
 You can use methods oncomponenttag and onxomponenttagbody to dynamically
 change the tag and the body depending on component status (view or edit)...
 Good luck :).
 On Feb 28, 2014 8:34 PM, Entropy blmulholl...@gmail.com wrote:

  Is there a way to have my textfield show as plain text when in a readonly
  mode rather than as a disabled textbox?
 
  Backup question: I can imagine making a panel to do this...having a
  textfield and label and hiding whichever I didn't want, but I would want
 my
  panel to bind to a textbox in the parent page and replace that tag
  (otherwise I would have two textboxes, right).  How would I go about
 that?
 
  --
  View this message in context:
 
 http://apache-wicket.1842946.n4.nabble.com/Show-textfield-as-plaintext-when-disabled-tp4664723.html
  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 



Re: Nested Forms

2014-01-10 Thread Chris Snyder
Nested form elements (what I'm assuming you're referring to) aren't
allowed, per the HTML spec:
http://www.w3.org/TR/html5/forms.html

I wouldn't expect Wicket to follow any kind of predictable behavior
(especially since different browsers likely exhibit different behaviors
themselves).

Best,
Chris

On Fri, Jan 10, 2014 at 12:04 PM, gmparker2000 greg.par...@brovada.comwrote:

 When submitting an inner form it appears that the request contains all of
 the
 outer and inner form fields.  Is this the expected behaviour?  From what I
 can see it appears that the outer form is submitted, and only the inner
 form
 parameters are validated and used for model updates.

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Nested-Forms-tp4663620.html
 Sent from the Users forum mailing list archive at Nabble.com.

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




Re: Prefixing CDN URL to resources base path

2013-12-13 Thread Chris Snyder
I'm planning to do something similar. In my searches, I came across the
following:
http://blog.55minutes.com/2012/01/simplecdn-and-the-newly-released-fiftyfive-wicket-32/

I haven't tried it yet, but it seems like a solid idea.

-Chris Snyder

On Fri, Dec 13, 2013 at 9:26 AM, Arjun Dhar dhar...@yahoo.com wrote:

 Hi,
 I'm trying to make the use of CDN hassle free with my Wicket Apps.
 .. where *IF* a CDN location is specified then all paths like



 .. become



 This applies to JS, CSS, and img tags mainly.

 Am wondering where the best place to automate this would be ?
 1. Build Process; do a REPLACE during production BUILD
 2. Wicket code that loads using IResourceStream UrlResourceStream(url) ;
 Intercept the raw HTML stream and re-generate it? (if this is cached may be
 efficient??)
 3. HttpServletFilter -- Just before its passed back from the Web Server.
 Do
 a RegEx scan and replace (Maybe too inefficient , but less intrusive to any
 Wicket Vodoo)

 Thoughts?



 -
 Software documentation is like sex: when it is good, it is very, very
 good; and when it is bad, it is still better than nothing!
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Prefixing-CDN-URL-to-resources-base-path-tp4662997.html
 Sent from the Users forum mailing list archive at Nabble.com.

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




-- 
Chris Snyder
Web Developer, BioLogos
biologos.org


SVG mime-type incorrect

2013-07-30 Thread Chris Snyder
I'm trying to serve SVG images as package resources. However, when I do so, the 
image files are served with a mime-type of application/xml, rather than the 
correct image/svg+xml. This causes strange behavior in Google Chrome - the 
image displays as a broken link when included in an img/ tag, but renders 
fine when the image URL is opened directly. If the resource is served from the 
main webapp directory rather than as a package resource, the correct mime-type 
is sent and Chrome displays the image properly.

Delving into the code, it appears that the problem is Java's 
URLConnection.guessContentTypeFromStream() method, which doesn't support SVG 
files. I've verified this problem on both the Apple-supplied Java 1.6 and the 
official Oracle Java 1.7, both on MacOS X.

What would be the best way to work around this issue? I tried creating my own 
custom PackageResource wrapper, which had its own PackageResourceStream 
wrapper, but it quickly got unwieldy (as well as being a nightmare for future 
maintainability).

My goal is to have a subclass of Image that returns either a reference to an 
SVG or a PNG depending on the browser version. I first noticed the mime-type 
problem with my subclass, but I verified that it also exists when using the 
standard Image class.

Thanks in advance for your help!
-Chris Snyder
--
Chris Snyder
Web Developer, BioLogos
616.328.5208 x203
biologos.org



Re: SVG mime-type incorrect

2013-07-30 Thread Chris Snyder
Hi Martin,

Thanks for the extremely prompt response. Unfortunately, it appears that 
Application#getMimeType isn't called for UrlResourceStream resources - 
UrlResourceStream#getData calls URLConnection#getContentType, at which point 
we've entrusted the mime-type to Java.

Versions I should have included in my first email: I'm using Wicket 6.9.1, 
using the Jetty server referenced in the quickstart.

Thanks,
Chris
--
Chris Snyder
Web Developer, BioLogos
616.328.5208 x203
biologos.org

On Jul 30, 2013, at 13:06, Martin Grigorov mgrigo...@apache.org wrote:

 Hi,
 
 You can override org.apache.wicket.Application#getMimeType
 
 
 On Tue, Jul 30, 2013 at 7:01 PM, Chris Snyder 
 chris.sny...@biologos.orgwrote:
 
 I'm trying to serve SVG images as package resources. However, when I do
 so, the image files are served with a mime-type of application/xml, rather
 than the correct image/svg+xml. This causes strange behavior in Google
 Chrome - the image displays as a broken link when included in an img/
 tag, but renders fine when the image URL is opened directly. If the
 resource is served from the main webapp directory rather than as a package
 resource, the correct mime-type is sent and Chrome displays the image
 properly.
 
 Delving into the code, it appears that the problem is Java's
 URLConnection.guessContentTypeFromStream() method, which doesn't support
 SVG files. I've verified this problem on both the Apple-supplied Java 1.6
 and the official Oracle Java 1.7, both on MacOS X.
 
 What would be the best way to work around this issue? I tried creating my
 own custom PackageResource wrapper, which had its own PackageResourceStream
 wrapper, but it quickly got unwieldy (as well as being a nightmare for
 future maintainability).
 
 My goal is to have a subclass of Image that returns either a reference to
 an SVG or a PNG depending on the browser version. I first noticed the
 mime-type problem with my subclass, but I verified that it also exists when
 using the standard Image class.
 
 Thanks in advance for your help!
 -Chris Snyder
 --
 Chris Snyder
 Web Developer, BioLogos
 616.328.5208 x203
 biologos.org
 
 



Re: SVG mime-type incorrect

2013-07-30 Thread Chris Snyder
However, just above that (line 122) it gets the contentType from the 
URLConnection, which returns application/xml. Since streamData.contentType is 
not null, it never gets to line 126.

Thanks so much for your help!

-Chris
--
Chris Snyder
Web Developer, BioLogos
616.328.5208 x203
biologos.org

On Jul 30, 2013, at 13:30, Martin Grigorov mgrigo...@apache.org wrote:

 Hi,
 
 According to
 https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/resource/UrlResourceStream.java?source=cc#L126
 if
 theere is an application then it should be used before falling back.



Re: SVG mime-type incorrect

2013-07-30 Thread Chris Snyder
Except that URLConnection#getContentType doesn't even use MimeTable:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/URLConnection.java?av=f#147

URLConnection#guessContentTypeFromStream is what it's using:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/net/URLConnection.java#URLConnection.guessContentTypeFromStream%28java.io.InputStream%29
Ugh - what a mess. That seems like a very arbitrary set of filetypes to test 
for (FlashPix?). It sees that the SVG file starts with ?xml…, so it returns 
application/xml - not wrong, per se - but not accurate enough.

 On my
 machine 
 System.err.println(URLConnection.getFileNameMap().getContentTypeFor(file.svg));
 prints null
Same here. However, the following returns application/xml (test.svg must be 
an SVG file, of course):
System.err.println(URLConnection.guessContentTypeFromStream(getClass().getResourceAsStream(test.svg)));

Thanks,
Chris
--
Chris Snyder
Web Developer, BioLogos
616.328.5208 x203
biologos.org

On Jul 30, 2013, at 13:52, Martin Grigorov mgrigo...@apache.org wrote:

 This is nasty indeed!
 
 According to
 http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/MimeTable.java#MimeTable
 the
 mime types are loaded from mailcap files.
 See man update-mime
 
 
 On Tue, Jul 30, 2013 at 7:40 PM, Chris Snyder 
 chris.sny...@biologos.orgwrote:
 
 However, just above that (line 122) it gets the contentType from the
 URLConnection, which returns application/xml. Since
 streamData.contentType is not null, it never gets to line 126.
 
 Thanks so much for your help!
 
 -Chris
 --
 Chris Snyder
 Web Developer, BioLogos
 616.328.5208 x203
 biologos.org
 
 On Jul 30, 2013, at 13:30, Martin Grigorov mgrigo...@apache.org wrote:
 
 Hi,
 
 According to
 
 https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/resource/UrlResourceStream.java?source=cc#L126
 if
 theere is an application then it should be used before falling back.
 
 



Re: SVG mime-type incorrect

2013-07-30 Thread Chris Snyder
Good catch - thanks. Though it turns out that the mailcap stuff is all a red 
herring - they're just a stub for some code that somebody (probably in 1996 or 
thereabouts) thought they'd implement someday:
 // For backward compatibility -- mailcap format files
 // This is not currently used, but may in the future when we add ability
 // to read BOTH the properties format and the mailcap format.

Here's where the actual content-type loading takes place:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/MimeTable.java#229

To get this working, I copied the content-types.properties file from the Java 
lib directory to in the package next to the Wicket Start class, added an entry 
for SVG (the stock file is quite sparse), and added the following line in 
Start#main:
 System.setProperty(content.types.user.table, 
 Start.class.getResource(content-types.properties).getPath());

After doing that, it works properly - the correct mime-type is served, and 
Chrome displays the image. This is hardly a good solution for a production 
environment, but it will suffice for now.

Given how much of a mess that Java code is, it seems to me that Wicket's 
UrlResourceStream#getData method should be modified to not call 
URLConnection#getContentType at all. The behavior for when getContentType 
returns null - ask the Application [if it exists], or consult 
URLConnection#getFileNameMap - looks to be better for all cases.

Thanks so much for your help. I'm just getting into Wicket programming, and am 
very impressed with the helpfulness of the community.

Thanks,
Chris
--
Chris Snyder
Web Developer, BioLogos
616.328.5208 x203
biologos.org

On Jul 30, 2013, at 14:23, Martin Grigorov mgrigo...@apache.org wrote:

 You are right.
 It tries with getHeaderName(String) which looks in MimeTable and falls back
 to by stream.
 I think you need to set the type in your mailcap file.
 
 
 On Tue, Jul 30, 2013 at 8:16 PM, Chris Snyder 
 chris.sny...@biologos.orgwrote:
 
 Except that URLConnection#getContentType doesn't even use MimeTable:
 
 http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/URLConnection.java?av=f#147
 
 URLConnection#guessContentTypeFromStream is what it's using:
 
 http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/net/URLConnection.java#URLConnection.guessContentTypeFromStream%28java.io.InputStream%29
 Ugh - what a mess. That seems like a very arbitrary set of filetypes to
 test for (FlashPix?). It sees that the SVG file starts with ?xml…, so it
 returns application/xml - not wrong, per se - but not accurate enough.
 
 On my
 machine
 System.err.println(URLConnection.getFileNameMap().getContentTypeFor(file.svg));
 prints null
 Same here. However, the following returns application/xml (test.svg must
 be an SVG file, of course):
 
 System.err.println(URLConnection.guessContentTypeFromStream(getClass().getResourceAsStream(test.svg)));
 
 Thanks,
 Chris
 --
 Chris Snyder
 Web Developer, BioLogos
 616.328.5208 x203
 biologos.org
 
 On Jul 30, 2013, at 13:52, Martin Grigorov mgrigo...@apache.org wrote:
 
 This is nasty indeed!
 
 According to
 
 http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/MimeTable.java#MimeTable
 the
 mime types are loaded from mailcap files.
 See man update-mime
 
 
 On Tue, Jul 30, 2013 at 7:40 PM, Chris Snyder chris.sny...@biologos.org
 wrote:
 
 However, just above that (line 122) it gets the contentType from the
 URLConnection, which returns application/xml. Since
 streamData.contentType is not null, it never gets to line 126.
 
 Thanks so much for your help!
 
 -Chris
 --
 Chris Snyder
 Web Developer, BioLogos
 616.328.5208 x203
 biologos.org
 
 On Jul 30, 2013, at 13:30, Martin Grigorov mgrigo...@apache.org
 wrote:
 
 Hi,
 
 According to
 
 
 https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/resource/UrlResourceStream.java?source=cc#L126
 if
 theere is an application then it should be used before falling back.