Re: New App - Best Practices
On Mon, 04 Oct 2010 17:49:07 +1000, Chris Colman wrote: >>You are also missing out on advantages like automatic schema updates, >>DB4O's own unique ID system, and other very useful parts of the DB4O > API. > > The way I use JDO I get all of those features but in a datastore > agnostic way. This is really interesting, albeit your solution uses non-open source tools that I could not specify as a dependency in our open source framework. We also didn't discuss DB4O's native queries, which are optimised on the fly, but we are wandering further off-topic, so I will send an email. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: New App - Best Practices
On Mon, 04 Oct 2010 00:45:26 -0400, Brian Topping wrote: > There's *always* a cost, but which one is cheapest (most efficient, > easiest to use, yada yada) in the end depends on a lot of localized > factors. If it did not, there would be a website that every developer > visited before starting a new project, and the anointed "best > technologies" for that moment would be listed there. Heck, you would be > able check boxes on the list and generate a POM from it... Very true. It is precisely the diversity of what the cost (TCO, etc.) is that allows project like Wicket to get off the ground. If nobody had been willing to try doing J2EE in a different way, then where would Wicket be? Cheers, Sam. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: New App - Best Practices
On Mon, 04 Oct 2010 12:59:43 +1000, Chris Colman wrote: >>Keep in mind though that adding a layer like this over DB4O will mostly >>remove the advantages that would make you want to choose DB4O in the >>first place. > > Not really AFAIK: The ability to not have to manage fetch depths that > JDO/DB40 gives you over raw DB40 gives you is a massive productivity > boost (not sure if the latest DB40 supports lazy loading or not yet). This is OT, but I feel it needs some correction. DB4O has had transparent activation (automatic loading of references if/ when needed) and transparent persistence (automatic update depth) for a while now. You byte code can even be automatically instrumented with TA/TP (but note code injection doesn't work with Scala, so we hand-code a few base relationship classes with TA instead). You are missing out on the main goal of DB4O: simplicity - the ability to store and query POJOs with zero configuration, even POJOs from other database-unaware APIs. You are also missing out on advantages like automatic schema updates, DB4O's own unique ID system, and other very useful parts of the DB4O API. > In any case coding to a standard persistence interface (JDO) > over a proprietary API is IMHO an insurance policy I can understand that, and I think that way too in some situations, but I reject the notion that there is no price to pay. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: New App - Best Practices
On Mon, 04 Oct 2010 11:36:48 +1000, Chris Colman wrote: > Forgot to mention: DataNucleus allows you to use a wide range of > datastores and switch between them without any code changes: eg., all > the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and some > others), Google Application Engine (GAE), LDAP, Excel plus loads more. > If you don't want to commit to an ORM/RDBMS then DN would provide that > level of protection against datastore 'lock in'. Keep in mind though that adding a layer like this over DB4O will mostly remove the advantages that would make you want to choose DB4O in the first place. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: New App - Best Practices
On Sun, 03 Oct 2010 20:40:04 -0300, Francisco Diaz Trepat - gmail wrote: > Now I am free to do whatever I want. This is the worst part. :-) I understand that feeling! When I started designing our web app framework, I picked the technologies from an enormous set of options that I thought would make app development as rapid and robust as possible. The title of your message "best practices" suggests though that you want to stick to the mainstream solutions. > So, ideas on what to use? If you want to avoid ORMs completely, you could consider an object database like DB4O as we have in Granite. Granite is currently is not quite complete and poorly documented, and written Scala not Java, but there is surely something you can use there if you want to go down a that path - even if its just ideas and sample code. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: announcing Granite - a Wicket-Scala-DB4O web application stack
You could still have couchdb as a database, and also there is the
beginnings of an object store layer tucked away in an experimental API,
but I think we will stick with DB4O for the primary database. Once you
see the ease with which you can store use DB4O, you will see why eg (in
Scala sorry):
// define a class
class C(var x:String), var y:Int)
// store an instance
db.store(new C("hi", 123))
// find all instances of C in the database
val query = Query[C]
query in db
Cheers,
Sam.
On Thu, 23 Sep 2010 19:58:03 -0700, 7zark7 wrote:
> Looks great, thanks for the link.
>
> +1 on CouchDB, et al vs only DB4o,
> Wicket+Scala+Couch is a really nice stack
>
>
> Thanks
>
> On 9/21/10 11:42 PM, Thomas Kappler wrote:
>> On 09/22/10 03:41, Sam Stainsby wrote:
>>> Today we officially announced our project to provide a
>>> Wicket-DB4O-Scala web application stack:
>>>
>>> http://sustainablesoftware.com.au/blog/?p=77
>>>
>>> "I’m pleased to announce a new web application framework, called
>>> Granite, and an associated set of reusable libraries, called Uniscala.
>>> Please note that this is a work in progress: we are not announcing a
>>> release yet, or even a beta. A number people have started asking about
>>> the project, and so I felt it would be helpful to let the wider world
>>> know what is going on."
>>>
>>> "Granite is a lightweight framework for the rapid development of web
>>> applications. It is based on the very cool and richly featured Apache
>>> Wicket web framework. Granite uses an embedded object database that
>>> avoids the need for SQL or Object-Relational Mappers (ORMs), and, in
>>> the Wicket tradition, is proud of, if not smug about, its distinct
>>> lack of external XML configuration files."
>>
>> Hey,
>>
>> I find that quite exciting.
>>
>> Now that you've done the hard work of fitting a non-relational store
>> into a Wicket-based framework, do you think it would be hard to
>> substitute other data stores such as Redis, CouchDB, BDB for DB4O?
>>
>> -- Thomas
>>
>>
>
> - 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: announcing Granite - a Wicket-Scala-DB4O web application stack
On Wed, 22 Sep 2010 14:19:17 +, Sam Stainsby wrote: > On Wed, 22 Sep 2010 15:34:15 +0200, Erik van Oosten wrote: > >> I have looked at the example and it looks very promising. >> >> However, if you want more attention there should at the absolute >> minimum be a bunch of links somewhere that give starting points for >> someone to understand the project. E.g. links to important classes, >> important examples. Either an architecture overview or a small >> programming guide would be great too of course :) > > Sure, it must seem pretty obscure to newcomers at the moment. There is a bit more information here now, but still a way to go on the doco side of things: http://sustainablesoftware.com.au/blog/?p=114 "Granite: a simple example step-by-step As a prelude to outlining the architecture of Uniscala Granite as it currently stands, I’m going to run through creating a very simple Granite example, starting from the Granite Maven archetype, and ending with the application running on Jetty that can store, display and update meaningful data in the DB4O database. I’m going to assume that you’ve have already checked out Uniscala, and built and installed it with Maven according to the quick start guide.If you’ve followed all of the steps in the guide for using the Maven archetype, you should already have an empty application called ‘myapp’ that will run under Jetty — we’ll use this as a starting point for our example.""" ... Cheers, Sam. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: announcing Granite - a Wicket-Scala-DB4O web application stack
On Thu, 23 Sep 2010 04:47:24 +1000, Chris Colman wrote: > You could abstract the datastore in the stack using JDO/DataNucleus. It > supports DB40. In fact as it also supports RDBMS you could easily create > a datastore agnostic Wicket/Scala stack - that would be most awesome! That's one path that I have considered. I'm more of a mind to provide an environment where there is one type of embedded "root" database, but you can still interact meaningfully with other types of database. In fact, my first client project using Granite is a reporting engine for an SQL database that hold gigabytes of log data from a network of health kiosks! I will get around to blogging about that at some stage. I guess you could even have the root database and a JDO facility. --Sam. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: announcing Granite - a Wicket-Scala-DB4O web application stack
On Wed, 22 Sep 2010 15:34:15 +0200, Erik van Oosten wrote: > I have looked at the example and it looks very promising. > > However, if you want more attention there should at the absolute minimum > be a bunch of links somewhere that give starting points for someone to > understand the project. E.g. links to important classes, important > examples. Either an architecture overview or a small programming guide > would be great too of course :) Sure, it must seem pretty obscure to newcomers at the moment. I plan to add more entries in our blog and use that text to build up a guide. Too much attention at this point in development might be unwarranted in any case :-) Topics will be along the lines of the overall architecture, how Granite's IoC works, and then an explanation of how DB4O is used in Granite. All of these are vital to write any serious Granite app. I also hope to add more examples. There might not be much material before the end of this financial quarter (the end of this month for us in Australia), as I'm busy finalising client commitments ... one of which involves delivering a project based on Granite. > Op 22-09-10 03:41, Sam Stainsby schreef: >> Today we officially announced our project to provide a >> Wicket-DB4O-Scala web application stack: >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: announcing Granite - a Wicket-Scala-DB4O web application stack
On Wed, 22 Sep 2010 08:42:20 +0200, Thomas Kappler wrote: > On 09/22/10 03:41, Sam Stainsby wrote: >> Today we officially announced our project to provide a >> Wicket-DB4O-Scala web application stack: > Now that you've done the hard work of fitting a non-relational store > into a Wicket-based framework, do you think it would be hard to > substitute other data stores such as Redis, CouchDB, BDB for DB4O? It's all a matter of building Wicket models that wrap IDs (or OID) and queries, so probably not hard. I'm not planning to abstract across databases for Granite though. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
announcing Granite - a Wicket-Scala-DB4O web application stack
Today we officially announced our project to provide a Wicket-DB4O-Scala web application stack: http://sustainablesoftware.com.au/blog/?p=77 "I’m pleased to announce a new web application framework, called Granite, and an associated set of reusable libraries, called Uniscala. Please note that this is a work in progress: we are not announcing a release yet, or even a beta. A number people have started asking about the project, and so I felt it would be helpful to let the wider world know what is going on." "Granite is a lightweight framework for the rapid development of web applications. It is based on the very cool and richly featured Apache Wicket web framework. Granite uses an embedded object database that avoids the need for SQL or Object-Relational Mappers (ORMs), and, in the Wicket tradition, is proud of, if not smug about, its distinct lack of external XML configuration files." - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AW: Jwicket and Wiquery
On Mon, 28 Jun 2010 16:29:51 +0200, Stefan Lindner wrote:
> Hi Josh,
>
> yes, jWicket does it the Wicket way.
> Generally you have a Behavior (e.g. DraggabeBehavior) extending wicket's
> AjaxBehavior.
So does Wiquery:
label = new Label("item-name", model)
draggableBehavior = new DraggableBehavior
draggableBehavior.setOpacity(0.75f)
draggableBehavior.setRevert(new DraggableRevert(true))
label.add(draggableBehavior)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket + Scala + Spring
> P.S. though one slight difficulty I've run into is the need to translate > between Scala and Java collections. Perfectly doable, and not a Wicket > problem, but takes a way some of the elegance of coding purely in Scala. I can confirm that Scala 2.8 makes it considerably easier to inter-work with Java collections. I am also using Scala with Wicket - and loving it. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Java Wicket Job Opportunity, Finland
On Sat, 19 Dec 2009 18:12:48 -0800, shetc wrote: > Finland, Finland, Finland > The country where I quite want to be! ^^^ Not the best job application I've seen :-) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket + Freemarker
There is my 1.4-compatible version here, although it is written in Scala rather than Java.: http://uniscala.svn.sourceforge.net/viewvc/uniscala/trunk/uniscala-wicket- freemarker/src/main/scala/net/uniscala/wicket/freemarker/ FreeMarkerPanel.scala?view=markup THe maven module is here: http://uniscala.svn.sourceforge.net/viewvc/uniscala/trunk/uniscala-wicket- freemarker/ -- Sam On Tue, 15 Dec 2009 16:42:47 +0100, nino martinez wael wrote: > bahh, googling for 2 secs : > > http://wicketstuff.org/wicket14/velocity/ (although not freemarker) > > http://fisheye3.atlassian.com/browse/wicket-stuff/trunk/wicket-contrib- freemarker > (probably need a minor upgrade to wicket 1.4) > > http://www.opensubscriber.com/message/wicket- deve...@lists.sourceforge.net/2057609.html > > 2009/12/15 Daan van Etten : >> No built-in support, as you can just use HTML. I have not seen any >> external support, but someone else might have built it. >> >> Regards, >> >> Daan van Etten >> >> Op 15 dec 2009, om 13:41 heeft sudhir543-...@yahoo.com het volgende >> geschreven: >> >>> Any one !! >>> Is there any built in (or any) support for freemarker ? >>> >>> >>> >>> >>> Sudhir NimavatSenior software engineer. Quick start global PVT LTD. >>> Baroda - 390007 >>> Gujarat, India >>> >>> Personally I'm always ready to learn, although I do not always like >>> being taught >>> >>> >>> >>> >>> >>> >>> From: "sudhir543-...@yahoo.com" To: >>> users@wicket.apache.org >>> Sent: Tue, 15 December, 2009 5:14:52 PM Subject: Wicket + Freemarker >>> >>> Can any one point me to some article, resource which explains how to >>> integrate Freemarker. Does wicket offer freemarker integration out of >>> box ! >>> >>> >>> >>> >>> Sudhir NimavatSenior software engineer. Quick start global PVT LTD. >>> Baroda - 390007 >>> Gujarat, India >>> >>> Personally I'm always ready to learn, although I do not always like >>> being taught >>> >>> >>> The INTERNET now has a personality. YOURS! See your Yahoo! >>> Homepage. http://in.yahoo.com/ >>> >>> >>> The INTERNET now has a personality. YOURS! See your Yahoo! >>> Homepage. http://in.yahoo.com/ >> >> >> - >> 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: How do you achieve persistency
On Tue, 06 Oct 2009 14:02:56 -0700, Igor Vaynberg wrote: > i think all the suggestions you have gotten until now are > overcomplicated and have a high learning curve. i think the easiest and > fastest way to achieve persistency is to use a database that all > operating systems already have - the file system. > > each "table" is a directory, each "entity" is simply a file that has the > serialized state of that entity named something like .ser. I suspect this is essentially what the Neodatis object database does (http://www.neodatis.org/), plus some trimmings such as OIDs and transactions, and making sure multiple copies of the same object are not saved. The tricky part is controlling the depth of the reference graphs that are saved/restored. DB4O has much more control over such things, such as being able to configure 'activation' depth, and also the option of instrumentation to activate references as required (transparent activation) or even persist automatically based on object changes (transparent persistence). However, be aware that DB4O is GPLed. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How do you achieve persistency
On Tue, 06 Oct 2009 09:34:55 +, Peter Arnulf Lustig wrote: > What's the fast and easy way? > > I am asking because of a lot of trouble with hibernate. You can use an object database (like DB4O) that doesn't require ORM. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket-Scala extensions
Looks good - I have some form-generation wicket-scala material that I'm
trying to get out. Fodels look interesting - I have something similar but
maybe not as general.
On Fri, 14 Aug 2009 18:56:09 +0200, Antony Stubbs wrote:
> Ok for those following this thread - Wicket-Scala Extensions is out!
> Announcement here:
> http://www.nabble.com/Announcing:-Scala-Wicket-Extensions-Project-
ts24975011.html
>
> Cheers,
> Antony Stubbs,
>
> sharca.com
>
> On 14/07/2009, at 11:34 AM, Antony Stubbs wrote:
>
>> omgosh -
>> http://www.footprint.de/fcc/2009/02/london-wicket-presentation/ I've
>> met you! haha. h... Isn't the internet nutty?!
>>
>> On 14/07/2009, at 7:14 PM, Jan Kriesten wrote:
>>
>>
>>> Hi Antony,
>>>
>>> great to see Scala and Wicket getting more popular. :-)
>>>
>>> I've been using them together quite a while now and am convinced that
>>> there are
>>> lots of benefits in it!
>>>
>>> I created a dynamic component (like wicket:component which isn't
>>> officially
>>> supported) which also works with Ajax. There's also a 'VarModel' which
>>> is
>>> similar to your Fodel. You'll find the sources here:
>>> http://www.footprint.de/fcc/2008/11/some-wicket-scala/
>>>
>>> I also use Scala's mixin capabilities to abstract layout information
>>> out of the
>>> pages/components. E.g. to define cell styles of datatable columns or
>>> to format
>>> cell output, I have something like:
>>>
>>> trait Centered[T] extends IStyledColumn[T] {
>>> abstract override def getCssClass: String = {
>>> val style = super.getCssClass
>>>
>>> if( style==null ) "columnCentered"
>>> else style + " " + "columnCentered"
>>> }
>>> }
>>>
>>> trait DateFormat[T] extends PropertyColumn[T] {
>>> override protected def createLabelModel( embeddedModel:
>>> IModel[T] ):
>>> IModel[_] = {
>>> val m = super.createLabelModel( embeddedModel ) m.getObject match
>>> {
>>> case dt: DateTime =>
>>> VarModel( dt.toString( dateFormatter.withLocale( getLocale ) ) )
>>> case _ => m
>>> }
>>> }
>>> }
>>>
>>> To create/apply a cell to use this style I just have to apply this
>>> trait:
>>>
>>> val col1 = new PropertyColumn[M]( new Model( "Date" ), COL_DATE,
>>> "reg_date" )
>>> with Centered[M] with DateFormat[M]
>>>
>>>
>>> Scala's just great to abstract more between logic and layout.
>>>
>>> Best regards, --- Jan.
>>>
>>>
>>>
>>> -
>>> 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: best or common practice for application plug-ins
Thanks Adrian for sending through the details. We are now also looking at Apache Geronimo that has some interesting features for plugins. Thanks all, Sam. On Mon, 20 Jul 2009 17:26:03 +0200, Adrian Wiesmann wrote: > Ping me offline for details since this is very much non-Wicket stuff. > > Cheers, > Adrian > > - 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: jWicket -- jQuery with Wicket integration
On Tue, 21 Jul 2009 02:18:12 -0700, Tauren Mills wrote: > I realize there are already a few Wicket/jQuery > integrations, but I think that Stefan's WicketJQuery implementation has > some advantages over the others. We've just started using WiQuery (http://code.google.com/p/wiquery/), but are not committed to it as yet. What would you say are the advantages of jWicket over WiQuery? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Thanks Olger, that gives me some ideas. I wonder if a maven could somehow be coerced to do the dependency/downloading part, perhaps with some new plugin. On Mon, 20 Jul 2009 13:39:10 +0200, Olger Warnier wrote: > Hi Sam, > > How we do it with that service: > > We have a file listener class that checks if OSGI based jar files are > put in a directory. > If so, these are automatically deployed to the OSGI runtime by the > BundleDeployer class. > We miss a download / version updates part, but you could add that by > downloading to the directory specfified by the FileListener. > > There is no need to restart, OSGI updates the whole automatically (we > use embedded felix for this). > Something to keep in mind, be careful with the OSGI versioning in this > as that puts versions next to eachother. > > This is used to provide custom, for our project - wicket based, user > interface functionality. > > Kind Regards, > > Olger > > > On 20 jul 2009, at 12:51, Sam Stainsby wrote: > >> OK, so I am an sys admin running some sort of OSGI-based application >> and >> now I want to add your questionnaire service and any other modules that >> it depends on. I also want to occasionally check for version updates. I >> want these updates and dependencies to be downloaded and put in the >> correct place for me so that when I restart the application, they are >> loaded. How do I do that? If it were Zope, I would add one line to a >> 'buildout.cfg' file and run the 'buildout' script, and restart Zope. >> >> On Mon, 20 Jul 2009 10:33:45 +0200, Olger Warnier wrote: >> >>> In our project we use OSGI to get a plugin structure. Interfaces >>> defined >>> in the 'core' layer are implemented in OSGI modules. For a simple >>> example see: http://www.joiningtracks.org/svn/his/trunk/ >>> questionnaire/ >>> (SVN code repo) >>> It's a questionnaire service that uses OSGI to load the question forms >>> (based on wicket) >>> >>> Our whole platform is constructed like that, the questionnaire service >>> is the most simple one and easily adapted for your own use. >> >> >> >> - >> 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: best or common practice for application plug-ins
OK, so I am an sys admin running some sort of OSGI-based application and now I want to add your questionnaire service and any other modules that it depends on. I also want to occasionally check for version updates. I want these updates and dependencies to be downloaded and put in the correct place for me so that when I restart the application, they are loaded. How do I do that? If it were Zope, I would add one line to a 'buildout.cfg' file and run the 'buildout' script, and restart Zope. On Mon, 20 Jul 2009 10:33:45 +0200, Olger Warnier wrote: > In our project we use OSGI to get a plugin structure. Interfaces defined > in the 'core' layer are implemented in OSGI modules. For a simple > example see: http://www.joiningtracks.org/svn/his/trunk/questionnaire/ > (SVN code repo) > It's a questionnaire service that uses OSGI to load the question forms > (based on wicket) > > Our whole platform is constructed like that, the questionnaire service > is the most simple one and easily adapted for your own use. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
On Mon, 20 Jul 2009 10:25:17 +0200, Linda van der Pal wrote: > Seeing how it looks like you want to create your own CMS, you might want > to have a look at Hippo CMS. They've built it in Wicket AFAIK. I've seen Hippo, but my main aim is not to create a CMS. One of my goal applications is more to do with identity management, but that's another story. However, I used CM as an example of something that could be added to the core framework. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
On Mon, 20 Jul 2009 09:10:57 +0200, Per Lundholm wrote: > Well, plug-ins, are they compile-time or run-time? Sounds like > compile-time from your description. Runtime I think if I understand you correctly. Suppose a sys admin has already deployed the war file for the core application and wants to add some functions. > Also, from your description, it sounds that it is more than web-tier. > Remember Wicket is web-tier only. > > There are solutions for the server tier for plug-ins. Look att OSGi > http://www.osgi.org and ESB. It could well be more than web-tier, but I thought if anyone has done this is would be a Wicket user :-) I looked at OSGi before I started my framework. I didn't see anything about deployment of add-ons/plug-ins. I already have a framework that incorporates IoC as a fundamental feature. Its the actual deployment of add-on functionality that interests me. ESB on first glance looks way too complicated, and I'm not sure it even does what I want. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Yes, different because I'm not talking about a collection of components per se, but how add-on components are deployed to an already running application by systems administrators, not developers, as per my initial post. On Mon, 20 Jul 2009 09:08:38 +0300, Martin Makundi wrote: > Different form wicket-stuff? > > http://wicketstuff.org/confluence/display/STUFFWEB/Home > > ** > Martin > > 2009/7/20 Sam Stainsby : >> Providing modules for others. And also providing an environment for >> third- party modules. See for example: >> >> https://svn.plone.org/svn/collective/ >> >> On Mon, 20 Jul 2009 08:29:51 +0300, Martin Makundi wrote: >> >>> What are you aiming at? Providing modules to others or building >>> software to your client/own company? >>> >>> In my opinnion modules are good for the public but not for internal / >>> sophisticated (=educated) use. >>> >>> ** >>> Martin >>> >>> 2009/7/20 Sam Stainsby : >>>> I'm probably revealing my inexperience with J2EE environments in >>>> asking this, but how do Wicket programmers typically handle >>>> application "add- ons" (or "plug-ins" or "modules"). >>>> >>>> I'm interested in emulating what happens in the Zope/Plone world >>>> (which is where I've come from). In the case of Zope, you have a tool >>>> called 'buildout' and configuration file (buildout.cfg) where you >>>> can, among other things, tell buildout what modules/plug-ins you want >>>> to install. You then run the buildout script, which will take care of >>>> finding dependencies, downloading your modules and dependencies and >>>> installing them into the right place. Then the next time you run >>>> Zope, those modules are available. >>>> >>>> Buildout used in this way is a tool used by sys admins after you have >>>> deployed your Zope instance. A concrete example might be to add LDAP >>>> authentication to Zope - this would involve using buildout to install >>>> the correct modules, and then going into Zope and configuring the >>>> LDAP components. I know it sounds very much like maven, and perhaps >>>> maven can be used in this way. But generally I have considered maven >>>> to be a developer tool - at least that is how I use it. >>>> >>>> In my current case, I have created a web application framework built >>>> using Wicket. I want to have a core component and the >>>> add-ons/plug-ins such as LDAP authentication, CMS components, etc. >>>> that can be installed easily into a generic Granite deployment. >>>> >>>> Does that makes sense? How have Wicket people approached this? >>>> >>>> Buidlout can also build and install modules you are developing, as >>>> well as configure parts of Zope (such as the timezone). Sometime you >>>> just use buildout to upgrade your modules. I'm interested in >>>> approaches that encompass that as well. I'm not to fussed about >>>> having to restart the server. >>>> >>>> >>>> - >>>> 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 >> >> >> > - 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: best or common practice for application plug-ins
Providing modules for others. And also providing an environment for third- party modules. See for example: https://svn.plone.org/svn/collective/ On Mon, 20 Jul 2009 08:29:51 +0300, Martin Makundi wrote: > What are you aiming at? Providing modules to others or building software > to your client/own company? > > In my opinnion modules are good for the public but not for internal / > sophisticated (=educated) use. > > ** > Martin > > 2009/7/20 Sam Stainsby : >> I'm probably revealing my inexperience with J2EE environments in asking >> this, but how do Wicket programmers typically handle application "add- >> ons" (or "plug-ins" or "modules"). >> >> I'm interested in emulating what happens in the Zope/Plone world (which >> is where I've come from). In the case of Zope, you have a tool called >> 'buildout' and configuration file (buildout.cfg) where you can, among >> other things, tell buildout what modules/plug-ins you want to install. >> You then run the buildout script, which will take care of finding >> dependencies, downloading your modules and dependencies and installing >> them into the right place. Then the next time you run Zope, those >> modules are available. >> >> Buildout used in this way is a tool used by sys admins after you have >> deployed your Zope instance. A concrete example might be to add LDAP >> authentication to Zope - this would involve using buildout to install >> the correct modules, and then going into Zope and configuring the LDAP >> components. I know it sounds very much like maven, and perhaps maven >> can be used in this way. But generally I have considered maven to be a >> developer tool - at least that is how I use it. >> >> In my current case, I have created a web application framework built >> using Wicket. I want to have a core component and the add-ons/plug-ins >> such as LDAP authentication, CMS components, etc. that can be installed >> easily into a generic Granite deployment. >> >> Does that makes sense? How have Wicket people approached this? >> >> Buidlout can also build and install modules you are developing, as well >> as configure parts of Zope (such as the timezone). Sometime you just >> use buildout to upgrade your modules. I'm interested in approaches that >> encompass that as well. I'm not to fussed about having to restart the >> server. >> >> >> - >> 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
best or common practice for application plug-ins
I'm probably revealing my inexperience with J2EE environments in asking this, but how do Wicket programmers typically handle application "add- ons" (or "plug-ins" or "modules"). I'm interested in emulating what happens in the Zope/Plone world (which is where I've come from). In the case of Zope, you have a tool called 'buildout' and configuration file (buildout.cfg) where you can, among other things, tell buildout what modules/plug-ins you want to install. You then run the buildout script, which will take care of finding dependencies, downloading your modules and dependencies and installing them into the right place. Then the next time you run Zope, those modules are available. Buildout used in this way is a tool used by sys admins after you have deployed your Zope instance. A concrete example might be to add LDAP authentication to Zope - this would involve using buildout to install the correct modules, and then going into Zope and configuring the LDAP components. I know it sounds very much like maven, and perhaps maven can be used in this way. But generally I have considered maven to be a developer tool - at least that is how I use it. In my current case, I have created a web application framework built using Wicket. I want to have a core component and the add-ons/plug-ins such as LDAP authentication, CMS components, etc. that can be installed easily into a generic Granite deployment. Does that makes sense? How have Wicket people approached this? Buidlout can also build and install modules you are developing, as well as configure parts of Zope (such as the timezone). Sometime you just use buildout to upgrade your modules. I'm interested in approaches that encompass that as well. I'm not to fussed about having to restart the server. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket-Scala extensions
Not yet, but I can make it available if there is interest.
Antony Stubbs wrote:
> Just a quick note, is the source available for all this?
>
> all I see is svn checkout
> file:///home/sam/work/svn_repository/uniscala/trunk uniscala
> on http://uniscala.net/source-repository.html
>
> On 14/07/2009, at 12:46 PM, Sam Stainsby wrote:
>
>> On Tue, 14 Jul 2009 11:38:33 +1200, Antony Stubbs wrote:
>>
>>> I'm very interested in people's suggestions of otherways of taking
>>> advantage of Scala to make Wicket programming easier.
>>
>> We are using Scala and Wicket intensively (and the DB4O object database
>> as well). One thing we are working on is Wicket form generation, which
>> touches on ideas that are similar to those you have discussed.
>>
>> This is what we can do today: consider this domain class:
>>
>> class MyRectangle(var width:Int, var height:Int) extends Serializable {
>> def area:Double = width*height
>> }
>>
>> we can then do:
>>
>> class MyRectangleSchema extends SimpleFieldsSchema[MyRectangle](
>> ReadWriteFieldSchema("width", _.width, _.width = _:Int),
>> ReadWriteFieldSchema("height", _.height, _.height = _:Int),
>> ReadOnlyFieldSchema("area", _.area)
>> )
>>
>> Above we are defining the accessors and mutators for each field except
>> the last which just has an accessor. We could probably use introspection
>> to make this much more succinct, and will likely provide this as an
>> option at some stage. As you see we don't use the JavaBeans conventions
>> as we find they are not very scala-ish, and so fully automatic
>> introspection is problematic.
>>
>> Creating a rectangle and schema first:
>>
>> val rectangle = new MyRectangle(width, height)
>> val schema = new MyRectangleSchema()
>>
>> we use a 'builder' object to create Wicket components:
>>
>> val builder = new ViewBuilder { }
>>
>> We can then create a simple 'view' thus:
>>
>> builder.createView("panel1", schema, rectangle)
>>
>> and a simple form like this:
>>
>> builder.createFormView("panel2", schema, rectangle,
>> new Button("submit") {
>>override def onSubmit = // .. do something ...
>> }
>> )
>>
>> Note that the above is completely type-safe. You can also mix and match
>> fields from different schemas, and create schemas for aggregate objects
>> by embedding (sub-)schemas inside other schemas. Builders can be
>> overridden to provider custom components for any fields that need them.
>>
>> This part of the project is still half-formed and fairly raw and
>> undocumented. Really only text fields are catered for. The javadoc is
>> here:
>>
>> http://uniscala.net/uniscala-view/scaladocs/index.html
>> http://uniscala.net/uniscala-view-wicket/scaladocs/index.html
>>
>> and is part of a larger project:
>>
>> http://uniscala.net/
>>
>> Apologies for lack of cross-linking between modules in the scaladoc - I
>> haven't worked out how to do this yet.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
--
Sam Stainsby - Managing Director
Sustainable Software Pty Ltd
"open knowledge :: social conscience"
ABN: 32 117 186 286
WWW: http://sustainablesoftware.com.au/
E-mail: s...@sustainablesoftware.com.au
Jabber: sjstain...@jabber.org
Tel/Fax: +61 7 3289 5491Mobile: +61 405 380 844
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket-Scala extensions
Done. Here is the code: http://uniscala.svn.sourceforge.net/viewvc/uniscala/trunk/ The overall aim of the project is to produce a web framework like Zope but for Scala instead of Python. That framework is in the 'unsicala- granite' module. The parts I was discussing were in the modules 'uniscala- view' and 'uniscala-view-wicket'. The 'uniscala-wicket' module currently just has an implicit model and is not that interesting (yet). There is also an example identity management application in its infancy in 'uniscala-topaz' - this uses the 'views' modules so might be a good place to look to see it in action. Not much doco yet - it will be a bit like walking into someone's laboratory and trying to guess what experiments they were doing. Some modules are purely experimental/playing. It's pre- alpha - I make no apologies :-) Cheers, Sam. On Tue, 14 Jul 2009 03:09:54 +, Sam Stainsby wrote: > No problem. I'll let you know when its available. Its just one of those > things I haven't gotten around to yet. > > On Tue, 14 Jul 2009 14:01:51 +1200, Antony Stubbs wrote: >> I'm much more interested in reading the source code, than reading the >> scaladoc :) >> you could put it up on git hub privately if you want? >> >> On 14/07/2009, at 1:10 PM, Sam Stainsby wrote: >> >>> Not yet, but I can make it available if there is interest. >>> >>> Antony Stubbs wrote: >>>> Just a quick note, is the source available for all this? > > > - 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-Scala extensions
No problem. I'll let you know when its available. Its just one of those things I haven't gotten around to yet. On Tue, 14 Jul 2009 14:01:51 +1200, Antony Stubbs wrote: > I'm much more interested in reading the source code, than reading the > scaladoc :) > you could put it up on git hub privately if you want? > > On 14/07/2009, at 1:10 PM, Sam Stainsby wrote: > >> Not yet, but I can make it available if there is interest. >> >> Antony Stubbs wrote: >>> Just a quick note, is the source available for all this? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket-Scala extensions
On Tue, 14 Jul 2009 11:38:33 +1200, Antony Stubbs wrote:
> I'm very interested in people's suggestions of otherways of taking
> advantage of Scala to make Wicket programming easier.
We are using Scala and Wicket intensively (and the DB4O object database
as well). One thing we are working on is Wicket form generation, which
touches on ideas that are similar to those you have discussed.
This is what we can do today: consider this domain class:
class MyRectangle(var width:Int, var height:Int) extends Serializable {
def area:Double = width*height
}
we can then do:
class MyRectangleSchema extends SimpleFieldsSchema[MyRectangle](
ReadWriteFieldSchema("width", _.width, _.width = _:Int),
ReadWriteFieldSchema("height", _.height, _.height = _:Int),
ReadOnlyFieldSchema("area", _.area)
)
Above we are defining the accessors and mutators for each field except
the last which just has an accessor. We could probably use introspection
to make this much more succinct, and will likely provide this as an
option at some stage. As you see we don't use the JavaBeans conventions
as we find they are not very scala-ish, and so fully automatic
introspection is problematic.
Creating a rectangle and schema first:
val rectangle = new MyRectangle(width, height)
val schema = new MyRectangleSchema()
we use a 'builder' object to create Wicket components:
val builder = new ViewBuilder { }
We can then create a simple 'view' thus:
builder.createView("panel1", schema, rectangle)
and a simple form like this:
builder.createFormView("panel2", schema, rectangle,
new Button("submit") {
override def onSubmit = // .. do something ...
}
)
Note that the above is completely type-safe. You can also mix and match
fields from different schemas, and create schemas for aggregate objects
by embedding (sub-)schemas inside other schemas. Builders can be
overridden to provider custom components for any fields that need them.
This part of the project is still half-formed and fairly raw and
undocumented. Really only text fields are catered for. The javadoc is
here:
http://uniscala.net/uniscala-view/scaladocs/index.html
http://uniscala.net/uniscala-view-wicket/scaladocs/index.html
and is part of a larger project:
http://uniscala.net/
Apologies for lack of cross-linking between modules in the scaladoc - I
haven't worked out how to do this yet.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: AW: AW: wicket on java server
On Wed, 10 Jun 2009 14:56:59 +0200, Dorothée Giernoth wrote: > No, worse, my boss :( he doesn't think tomcat is safe enough and doesn't > know how tomcat works and what's going on behind the scenes ... and we > can't have that I bet he won't let me use wicket ... b/c it's not > safe enough either *shakes head* weirdo Paranoid? I bet ... Maybe just use Jetty if that suits. Simpler and certainly extremely easy to set up and test with maven. We do this for one client for an app that is only used by a handful of people. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: What's the simplest way to do Context-sensitive Authorization in Wicket?
My code was bigger but I didn't want to brag :-) On Tue, 26 May 2009 23:11:06 -0700, Igor Vaynberg wrote: > i was being facetious :) > > -igor > > On Tue, May 26, 2009 at 10:39 PM, Jeremy Thomerson > wrote: >> I didn't mean than yours - Igor - I meant more than the original >> request. He simply requested basically exactly what you gave him. In >> mine, each permission can be granted dynamically in the DB. You can be >> given edit, delete, view, or add permissions each by section of the >> site / category of the content within that section, etc. It's much >> more extensible, at the cost of being much more complicated. >> >> So, I was just adding to it - not putting yours down - since yours is >> exactly what he requested. >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> >> >> >> >> On Wed, May 27, 2009 at 12:26 AM, Igor Vaynberg >> wrote: >>> On Tue, May 26, 2009 at 9:57 PM, Jeremy Thomerson >>> wrote: >>> (mine is actually much more complex and dynamic than yours, but this is the basic idea that you could apply to yours and build with your domain) >>> >>> i hope so - seeing how mine was written in about ten seconds :) >>> >>> -igor >>> >>> - >>> 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: What's the simplest way to do Context-sensitive Authorization in Wicket?
On Wed, 27 May 2009 10:33:40 +1000, Ben Hutchison wrote: > So the authorization decision needs to examine some context (ie the > Listing), as well as the current user, to determine whether they have an > Edit or View role. I'm building something in that does this (albeit in scala). The approach I used was to implement a custom IAuthorizationStrategy. The isActionAuthorized method takes a component, so you can use the component, or its model, or both, as a starting point for your context. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and 3rd party Javascript libraries
On Thu, 21 May 2009 20:32:01 -0500, Vasu Srinivasan wrote: > Apologize if this question sounds too generic... Are there restrictions > in using 3rd party Javascript libraries when using Wicket? We have a > separate design/javascript team and they love the idea of having just > html to work with. But there is also a need of freedom/flexibility in > adding custom javascript solutions (eg DWR, Dojo etc) Will Wicket's > javascript libraries get in the way ? Incidentally whats the javascript > library kit that Wicket uses by default ? I've just been using Wiquery, a (currently alpha-ish) framework that integrates JQuery and Wicket. I was able to JQuery-enable my application framework and make it themeroller-ready in the space of an evening. My understanding is that there is a lot of work to go on Wiquery, but it seems to be usable, and a good start rather than working it all out for yourself. Having said that, I haven't done much more than pop up a dialog box and play with themeroller so far. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Turning off ModificationWatcher
On Thu, 09 Apr 2009 08:41:20 +0200, Martijn Dashorst wrote: > Never *EVER* deploy your application in development mode. Use deployment > mode and turn those features you want on. Just curious - does something catastrophic happen? I'm running a testing demo for a client and haven't bothered turning off development mode (I assume it is on by default?). It runs fine. Cheers, Sam. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket-like framework to complement wicket?
On Fri, 05 Sep 2008 15:21:34 +0200, francisco treacy wrote: > good! but i personally restrain from using db4o as its license is quite > restrictive. that's why i'm supporting neodatis, which is slowly gaining > momentum. Isn't DB4O released under GPL, as well as a commercial license? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Melbourne, Australia Wicket group
Brisbane is better than both :- ) (that's where I live). On Mon, 26 May 2008 18:48:03 -0700, Jonathan Locke wrote: > I liked Sydney a lot, but never been to Melbourne. > > > Eelco Hillenius wrote: >> >>> I'm interested in forming a Melbourne Wicket group, along the lines of >>> http://www.londonwicket.org. >> >> Nice to be represented in that part of the world! I spent three months >> in Melbourne as a tourist and I think it's one of the coolest towns I >> know. >> >> Good luck, >> >> Eelco >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] For >> additional commands, e-mail: [EMAIL PROTECTED] >> >> >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Account Activation Email generation and response processing: any design example?
You must be either storing the hash, or the data that you are hashing to regenerate the hash. On Mon, 19 May 2008 08:40:36 +0300, Martin Makundi wrote: > If you use hash you do not need to store the "random" part into the db. > Saves you some persistence trouble. > > 2008/5/19 Michael Allan <[EMAIL PROTECTED]>: >> Sam Stainsby wrote: >>> >>> Martin Makundi wrote: >>> > The benefit in digest is that the user (or another user) cannot >>> > fabricate it... so easily. >>> >>> Just send a large random number ... no need for expensive hash >>> operations. >> >> But use java.security.SecureRandom, not java.util.Random. >> >> -- >> Michael Allan >> >> Toronto, 647-436-4521 >> http://zelea.com/ >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] For >> additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > - To > unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Account Activation Email generation and response processing: any design example?
On Fri, 16 May 2008 21:15:34 +0300, Martin Makundi wrote: > The benefit in digest is that the user (or another user) cannot > fabricate it... so easily. Just send a large random number that is unique on the server. Keep a copy and compare with what the recipient sends back. Simple - no need for expensive hash operations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A few Wicket Questions
On Tue, 08 Apr 2008 17:29:16 -0700, Michael Mehrle wrote: > In general, Wicket does a great job of giving your trace output of your > template when something goes awry, including the component inheritance > and suggestions as to what could be wrong. And for that I am *very* thankful. I've only just started using wicket, for some new experimental work (combined with YUI and DB4O). Those error traces that simply tell you what is wrong and precisely where have saved me many of those painful hours that you normally experience when adapting to a new framework. Thanks Wicket developers, this and other aspects of Wicket (and DB4O too!) have converted me back to using Java. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
