Re: Wicket with some servlet container on Android?
Hi Sven, On Sun, Jun 21, 2015 at 4:06 PM, Sven Meier s...@meiers.net wrote: Hi Martin, It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. yeah, time to improve that :). If anyone provided patches and/or pull requests to remove those dependencies, I'd be willing to support these changes. Do you see a big benefit in doing this? Except better abstractions than now and because we can. I might have time to work on this soon but I'll need a good technical reason to do it first. Regards Sven On 21.06.2015 13:49, Martin Grigorov wrote: Hi On Sun, Jun 21, 2015 at 1:06 PM, Sven Meier s...@meiers.net wrote: Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Few years ago I've tried to replace Servlet impl with one based on Netty. There are many places in Wicket core where we use/cast to Servlet APIs. For example Form.java does it. Some classes use Cookie. Some internal classes use event listeners (PageStoreManager.java). I've stopped working on due to lack of time and interest. It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket with some servlet container on Android?
Hi Martin, It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. yeah, time to improve that :). If anyone provided patches and/or pull requests to remove those dependencies, I'd be willing to support these changes. Regards Sven On 21.06.2015 13:49, Martin Grigorov wrote: Hi On Sun, Jun 21, 2015 at 1:06 PM, Sven Meier s...@meiers.net wrote: Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Few years ago I've tried to replace Servlet impl with one based on Netty. There are many places in Wicket core where we use/cast to Servlet APIs. For example Form.java does it. Some classes use Cookie. Some internal classes use event listeners (PageStoreManager.java). I've stopped working on due to lack of time and interest. It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dealing with transient and persistent objects in Wicket sessions and models
For persistence, I use the ActiveObjects ORM library, originally developed by Daniel Spiewak and now actively maintained by Atlassian. In AO, database entities are described by java interfaces. For your use case (transient objects that may or may not be persisted), I use a dynamic proxy whose implementation can be serialized. When setters are called on the entity, the proxy stores the (unsaved) data in a HashMap. An actual database record is only created on an explicit call to entity.save(). By implementing it this way, panels that manipulate database records can operate on either new (transient) records or records that already exist. If the user cancels without saving, there is no detritus in the database to clean up. If anyone out there is interested in using AO with Wicket, I’d be happy to share my code experience. I like the AO programming model, and its support for automatic schema migration means that you can change table definitions by adding/removing setters and getters in the entity interfaces; AO can infer the SQL to migrate tables to the new schema. For a quick (but somewhat outdated) introduction to AO, see: https://activeobjects.java.net/0.8.2/ActiveObjects.pdf https://activeobjects.java.net/0.8.2/ActiveObjects.pdf The repository can be found here: https://bitbucket.org/activeobjects https://bitbucket.org/activeobjects It’s an obscure framework, but I find it a pleasure to use, and it plays reasonably well with Wicket. -Don On Jun 19, 2015, at 3:43 AM, Urbani, Edmund edmund.urb...@lilandit.com wrote: On 06/19/2015 01:59 AM, wix wrote: Urbani, Edmund wrote I don't think I am the only one running into these kinds of issues, so I'd like to hear which patterns other developers apply or what they consider best practices. Would like to hear the same. I've attempted to work through this in the most Wicket-way I know how. The approach so far is a kind of LoadableDetachableModel that tries to be smart about the persistent state of the underlying entity/object. A persistence provider (entitymanager or such) would be injected into the model or requested by the model, and a flag or flags used to track the state of the underlying entity - is the entity currently managed? is the entity to be retained (that is, not automatically detached)? is the entity currently attached? So at the start of a wizard, the model is given a new entity and told that it is un-managed and retained. As the model is passed to the next page or to a previous page, the entity is serialized (not detached) and treated as though it doesn't belong to a persistence context. At the end of the wizard the model is told to persist the entity at which time it becomes managed but not retained (so it detaches, and would be re-attached via persistence id lookup when the model is next deserialized/loaded). A wizard or other set of pages working with an existing entity that was selected from persistence just tells the model that it is managed and retained. Then the model still doesn't detach in the sense of setting the underlying entity to null, but it does detach from the JPA context and is safely(?) serialized. Thereby changes made in wizard pages ride along to the end as in the new entity case above, and aren't merged til whatever final page/part logic says so. Cancelling out in the middle is simple since no changed would have been persisted. It works for any generic entity in my projects so far, however my use case right now isn't complicated by multi-entity editing; only one entity (one model's underlying object) is being modified by a single form submission in the open-session-in-view cycle. If there are other drawbacks to this approach or a better way (a more Wicket-way)... Detaching from Hibernate / JPA session as you describe is another way to handle this. Makes me worry about concurrent modifications which might be committed in between detaching from / re-attaching to the persistence layer though. Also, I have considered separating the presentation layer (Wicket) from the managed database objects entirely and handle every interaction with the database through a service layer which maps database objects to/from a different set of classes tailored specifically for the UI and its various use cases. That would be the cleanest approach I can think of, and also the most expensive one to implement. However, currently I am trying to hook into the serialization process to untangle my partially persistent object graph as described in this article: http://techblog.molindo.at/2009/03/detaching-and-attaching-persistent-objects-on-serialization.html http://techblog.molindo.at/2009/03/detaching-and-attaching-persistent-objects-on-serialization.html This seems to be working so far (pending some thorough testing) even though it causes some weird exceptions in unit tests (javassist.CannotCompileException), which I have yet
Re: Wicket with some servlet container on Android?
Hi On Sun, Jun 21, 2015 at 1:06 PM, Sven Meier s...@meiers.net wrote: Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Few years ago I've tried to replace Servlet impl with one based on Netty. There are many places in Wicket core where we use/cast to Servlet APIs. For example Form.java does it. Some classes use Cookie. Some internal classes use event listeners (PageStoreManager.java). I've stopped working on due to lack of time and interest. It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket with some servlet container on Android?
Hi, AFAICS i-jetty is the most promising one. But Netty project claims to support Android as an environment! [1], [2]. Netty doesn't support server side http sessions, so we should either implement custom ISessionStore ourselves (Apache CFX already has such impl, using Servlet APIs [3]) or use something like Hazelcast, Redis or Memcached. When running in Android there will be just one client so it could be simplified. @Thorsten: please tell me that i-jetty works fine and let me enjoy the summer :-) 1. http://netty.io/wiki/new-and-noteworthy-in-4.1.html 2. https://github.com/netty/netty/issues/2330 3. http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-transports-http-netty-server/3.0.0/org/apache/cxf/transport/http/netty/server/servlet/NettyHttpSession.java#NettyHttpSession Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Sun, Jun 21, 2015 at 11:24 PM, Sven Meier s...@meiers.net wrote: Hi Martin, if there's a workable servlet container for Android, I'd just use that. Except because we can I have to admit, that's the main reason for my suggestion :P. Have fun Sven On 21.06.2015 15:19, Martin Grigorov wrote: Hi Sven, On Sun, Jun 21, 2015 at 4:06 PM, Sven Meier s...@meiers.net wrote: Hi Martin, It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. yeah, time to improve that :). If anyone provided patches and/or pull requests to remove those dependencies, I'd be willing to support these changes. Do you see a big benefit in doing this? Except better abstractions than now and because we can. I might have time to work on this soon but I'll need a good technical reason to do it first. Regards Sven On 21.06.2015 13:49, Martin Grigorov wrote: Hi On Sun, Jun 21, 2015 at 1:06 PM, Sven Meier s...@meiers.net wrote: Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Few years ago I've tried to replace Servlet impl with one based on Netty. There are many places in Wicket core where we use/cast to Servlet APIs. For example Form.java does it. Some classes use Cookie. Some internal classes use event listeners (PageStoreManager.java). I've stopped working on due to lack of time and interest. It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket with some servlet container on Android?
Hi Martin, if there's a workable servlet container for Android, I'd just use that. Except because we can I have to admit, that's the main reason for my suggestion :P. Have fun Sven On 21.06.2015 15:19, Martin Grigorov wrote: Hi Sven, On Sun, Jun 21, 2015 at 4:06 PM, Sven Meier s...@meiers.net wrote: Hi Martin, It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. yeah, time to improve that :). If anyone provided patches and/or pull requests to remove those dependencies, I'd be willing to support these changes. Do you see a big benefit in doing this? Except better abstractions than now and because we can. I might have time to work on this soon but I'll need a good technical reason to do it first. Regards Sven On 21.06.2015 13:49, Martin Grigorov wrote: Hi On Sun, Jun 21, 2015 at 1:06 PM, Sven Meier s...@meiers.net wrote: Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Few years ago I've tried to replace Servlet impl with one based on Netty. There are many places in Wicket core where we use/cast to Servlet APIs. For example Form.java does it. Some classes use Cookie. Some internal classes use event listeners (PageStoreManager.java). I've stopped working on due to lack of time and interest. It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[ANNOUNCE] WicketStuff 6.20.0 is released
Hi, WicketStuff core 6.20.0 based on Apache Wicket 6.20.0 is released and available at Maven Central. The changelog since 6.19.0 is: cmiles74 (13): [openlayers3] Altered to pull OL resources with WebJars [openlayers3] Removed reference to undocumented dispose call [openlayers3] Fixed whitespace issue [openlayers3] Implemented an extent object [openlayers3] Altered click handler to only handle single clicks Merge branch 'wicket-6.x' of https://github.com/wicketstuff/core into wicket-6.x [openlayers3] Updated the URLs for the WFC examples Merge branch 'wicket-6.x' of https://github.com/wicketstuff/core into wicket-6.x [openlayers3] Added warning to the cluster demo page [openlayers3] Fixed issue with flickering popups [openlayers3] Fixed styling issue on the cluster example [openlayers3] Updated ignore file Merge branch 'wicket-6.x' of github.com:wicketstuff/core into wicket-6.x Andrea Del Bene (12): trying to use the last version of glassfish Revert trying to use the last version of glassfish Revert trying to use the last java 6 compatible version of gae Issue #383 updated dependency to 6.20.0-SNAPSHOT and added webjar to PackageScanner (Issue #383) Issue #384 stateless components ported to 6.x Update README.md response type is set now also for void methods updated readme file issue #399 updated dependencies on Gson and JAckson Alexander Morozov (6): [select2] Reformat code according to http://mvnrepository.com/artifact/org.apache.wicket/wicket-eclipse-settings [select2] Added Select2ChoiceTest that reproduces issue with loosing value by Select2Choice after form submit. - Override convertInput() and convertValue() in order to convert and process properly Select2Choice validation phase. - Override getInputAsArray() for Select2MultiChoice in order to satisfy FormComponent's contract. Implement convertValue() with ChoiceProvider. [select2] Fix issues after PR review. Thanks to martin-g. [select2] Fix IChoiceRenderer support. Added examples with stateless Select2Choice component. [select2] Always return a collection instead of null in Select2MultiChoice#convertValue(String[]) [select2] Update select2 README. Martin Grigorov (6): Merge pull request #387 from cmiles74/wicket-6.x Merge pull request #391 from shuraa/wicket-6.x-fix-select2-formatting Merge pull request #396 from shuraa/wicket-6.x-fix-select2-stateless-behavior Merge pull request #400 from cmiles74/wicket-6.x Merge pull request #407 from cmiles74/wicket-6.x Merge pull request #409 from shuraa/wicket-6.x-fix-408 klopfdreh (4): CanvasImage - Renders image into HTML content jee-web / html5 - destory WicketTester [minis] ReplacingResourceModel [minis] ReplacingResourceModel - title fix of test JoachimRohde (2): [GMap3] Corrected commit ee39d84a39240362e29d9dda6819877e2d398fa3 where another commit was cherry-picked into the wrong folder. [GMap3] Updated Marker-example to show how to use the new GAnimation class. Fixed image-paths. jrohde (2): [GMap3] Until version 3.10 of the Google Maps JavaScript API, complex icons were defined as MarkerImage objects. The Icon object literal was added in version 3.10, and replaces MarkerImage from version 3.11 onwards. Added the class GAnimation to customize the animation of a marker. [GMap3] Fixed broken JavaScript Joachim Rohde (1): [GMap3] Deprecated methods which are not supported by Google Maps anymore. Martin Tzvetanov Grigorov (1): Release 6.20.0 Maxim Solodovnik (1): Merge pull request #395 from shuraa/wicket-6.x-fix-issue-390 The WicketStuff team!
Session Scope
Hi all, I have a class annotated with @Scope(value = session, proxyMode = ScopedProxyMode.TARGET_CLASS)“. How is it possible to disable this attribute when calling this class from a main class, i.e. no session context? Thanks a lot, Chris
Re: Session Scope
Hi, This is Spring question, not Wicket. You should ask in Spring forums or StackOverflow.com. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Sun, Jun 21, 2015 at 9:20 PM, Chris chris...@gmx.at wrote: Hi all, I have a class annotated with @Scope(value = session, proxyMode = ScopedProxyMode.TARGET_CLASS)“. How is it possible to disable this attribute when calling this class from a main class, i.e. no session context? Thanks a lot, Chris
Re: up to date Wicket presentation?
Good morning, On my side of the planet it is 9am in Bordeaux and I feel myself a crushing desire to be with people who can speak my language, so here I am :-) I have written http://hatchetharry.net with a little help from my friends (as a well-known song says) and something which I feel absolutely surprising (hum) is that I was myself looking for a simple presentation in order to explain to other friends how wicket works. Guys: are you reading my mind or is it just a pure coincidence? :-) Yours sincerely, Zala Le 16 juin 2015 05:33, Ernesto Reinaldo Barreiro reier...@gmail.com a écrit : Thanks Andrea! On Mon, Jun 15, 2015 at 4:52 PM, andrea del bene an.delb...@gmail.com wrote: Hi, sorry if I take part to this conversation only now, but I realized that I do have a presentation (in English) I used for a crush-course on Wicket 6. It doesn't cover every topic of the framework but it might help you. Here's the link: https://www.dropbox.com/s/e41qr6mwsnsabkh/Presentazione%20Wicket.odp?dl=0 On 12/06/2015 12:06, Ernesto Reinaldo Barreiro wrote: Dear Wicketeers, Does anyone has, and is willing to share, a recent (in English) presentation of Apache Wicket? I mean newer than http://www.slideshare.net/jbaruch/wicket-presentation-alphacsp-java-web-frameworks-playoff-2008 which is, by the way, a nice presentation :-) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro
Re: Making a datatable more accessible
Thanks very much, I'll give it a try.
sent from my mobile device
On 19 Jun 2015 4:34 am, Sven Meier s...@meiers.net wrote:
Hi,
it's a little bit finicky, but it can be done:
DataTable dataTable = new DefaultDataTableContact,
String(table, columns, new SortableContactDataProvider(), 8) {
protected ItemIColumnContact, String newCellItem(final
String id, final int index, final IModelIColumnContact, String model)
{
return new ItemIColumnContact, String(id, index,
model) {
@Override
protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
// parent is the repeater for the cells, its
parent is the row
Contact contact = (Contact)
getParent().getParent().getDefaultModelObject();
if (contact.isSpecíal()) {
tag.setName(th);
}
}
};
}
};
In a future version we might want to change #newCellItem() to get a
reference to the row's model - that would remove the need to lookup the row
object from the grandparent.
Have fun
Sven
On 18.06.2015 14:15, Steve Swinsburg wrote:
Hi all,
I have a datatable and need to make it more accessible for screenreaders.
I am using an AbstractColumn and setting the getHeader and populateItem
methods with the contents.
In a particular row I want to change the markup of the cells from TD to
TH,
as they are header type content. Is this possible in Wicket, to change the
HTML tag? This is generated markup within the DataTable component so I'm
wondering if we can influence the HTML tag that is output.
The second issue is that when using getHeader to set the header cell
contents, it outputs this into a span within the TH, not directly within
the TH itself. I need to add the 'scope=col' ARIA attribute to the TH
but
cannot access it (even via getParent()). Again, generated markup.
Thanks for any assistance.
regards,
Steve
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket with some servlet container on Android?
Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket with some servlet container on Android?
Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
