SVG mime-type incorrect
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
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
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
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
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.
Re: Prefixing CDN URL to resources base path
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
Re: Nested Forms
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: 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.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: Show textfield as plaintext when disabled?
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
Best practice for updating JPA object without persisting changes
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
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
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
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: The wicket way of getting application base URL
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
Re: Introducing Croquet: Combining Wicket, Jetty, Hibernate, and Guice
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: Introducing Croquet: Combining Wicket, Jetty, Hibernate, and Guice
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
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
