Hi Jean, thank you for comments and for rpc preview, I will take a look.
And about our application it's not as simple as it seems. I'm using qooxdoo only for administration part (so this is why i need rpc integration) and wicket for standard web presentation / some logic (it's ecommerce). So qooxdoo is used only by administrators, not the users. I have strong reasons to keep these parts separate and not to use qooxdoo as standard web view (it's too heavy and in fact I don't see benefit of using it here). And about http sessions, you are right. I'm not big fan of 'write all in java' and ' store all in server' thing, but wicket seems for be the best framework here - it's quite good designed and hacking is quite easy, the community is also good :) Another thing that is interesting is your recommendation of OpenJPA, it must try it. I'm quite new to java world and I don't know all possibilities, but currently I have very evil deadline so I don't know when I could start learning it. BTW: Are you using Spring? Cheers - Petr 2009/9/18 Jean-Baptiste BRIAUD -- Novlog <[email protected]>: > Hi Petr, > > I'm still wondering why do you need Wicket or other frameworks in such > architecture ? > Page or View from such framework use to provide HTTP answer containing > that bloody boiler plate HTML + Data +js hack for ajax but thanks to > qooxdoo that delivered us from that horrible thing (ok, it is in fact > a little bit less horrible with Wicket), all your server had to do is > to answer JSON string, so no need for complex things. In fact, if you > don't have other constraints like it must be Wicket because of legacy > code or other integration, I would suggest you give a try to the > simple software architecture we are using. > > If you go that way, you even bebefit from a revolutionary thing : no > more HTTP session is needed on server side and so it scale better. > Each request, you keep the context on client side (thanks again to > qooxdoo) and you repost the context as parameter to the server. This > will allow you to have stateless server : this is a huge advantage to > scale. > You're using the client side CPU and only the server side one for what > it is good for : commom business rules and persistence. > > To me, all that struts like framework, even the new wicket, the HTTP > session on server side, cookie and so on are just old school. > > The RPC servlet will find the required service for an HTTP request > which will allow you to organize your code SOA ready spreading > business server entry point in Java service classes that are not more > complex than a simple class that even do not have to inherit from > something ! Which framework allow your business server classes to be > so simple ? > This architecture fully comply with KISS pattern :-) > > For the persistence, use OpenJPA or Hibernate if you can't use OpenJPA > which is just more powerful (fetch plan is a *killer* feature) and > standard (an Apache project). > Business objects are kept as simple as POJO, going from database to > Java (thanks to OpenJPA) then to javascript (thanks to RPC > serialisation) and come back the same way. > All that is transactional, simple, powerful (not verbose), scallable > and also rich (like in RIA) : that is 21st century IT architecture ;-) > > All that is ready to work but not deeply tested hadn't been stressed > for performance. My general point of view on performance is to design > the stuff the best you can, don't pospone design decision. After that, > just make it work without caring about perf. Then only, optimise. > > I'm OK to share all that code that include few qooxdoo subclass, a > modified Java RPC and few Java classes. > > More precisely on Java RPC, I'll send it to you right now as a big zip. > Let's just clarify one point about the license of that code. If > community found an interest to that code, I'd like to share it as the > second iteration on Java RPC contrib. > So, the license of the content of that zip is exactly the same as > current Java RPC contrib. Is that OK for you ? > > On the doc point of view, I have to warn you the level is 0 K which > mean zero degree Kelvin (-273.15 degree Celsius), quite cold isn't it ? > I just fight with the code to make all that work, it need to be > refactored and documented. > Another point (yes, I know, its a lot) you'll need at least Java 5 and > probably Java 6 which is the only JDK I'm using. > This is because I used annotations, generics, ... > For example, (hey, this sound like the beginning of a small doc, isn't > it ?) each service method may have extra parameters that are hidden > from javascript point of view. > This is usefull for passing technical parameters like OpenJPA > entityManager instance, manage transaction, .... So the servlet > prepare all that just before entering in the introspection code that > find the correct method on the service. > To let the user choose the type of that parameters, I'm using generics > and Java variable parameters method which come with Java 5. > > HTH ! > > > On Sep 18, 2009, at 17:11 , Petr Kobalíček wrote: > >> Hi Jean, >> >> if you have changes, it would be nice to share that :) >> >> I'm using apache wicket and I want to integrate RPC with their >> RequestCycle and custom Sessions. I can make page that responds in >> JSON, but this is not what I exactly need:) >> >> First I must explore the qooxdoo rpc package, I will ask if there will >> be something unclear >> >> Thanks >> - Petr >> >> 2009/9/17 Jean-Baptiste BRIAUD -- Novlog <[email protected]>: >>> >>> On Sep 17, 2009, at 09:47 , Petr Kobalíček wrote: >>> >>>> Hi Jean, >>>> >>>> thanks for response. >>>> >>>> Currently my needs are a bit unspecified. We are started one >>>> application in java and I'm still learning things (not java, but the >>>> libraries we are using). My needs are that I should be able to work >>>> with POJOs (like you said), but sometimes I would probably need to >>>> include much more (not only getters / setters, add some data to rpc >>>> response). >>>> >>> Do you mean adding data on the javascript side ? If yes, witch >>> attribute will receive that on the java side ? >>> It could work if you just leave a empty (null) attribute on the way >>> java to js and then js will just fill it. >>> Then, you might args that is has a cost (on bandwidth on the way java >>> to js) but I suggest you'll see that when everything will works. >>> >>> I would also like to add one more engencement I had to do : it is not >>> on the serialization part but on the "service" part. >>> Rather than forcing the exact match of method parameters, I allow >>> some >>> parameter not to be filled on js side but on Java side before the >>> call >>> to service. >>> This allow me to have technical parameter to pass to all services. It >>> is used for transaction, passing database session, ... Any generic >>> technical params that has to be on service but not on js side. >>> >>>> Are you using JavaRPC together with Hibernate? >>> I'm using it with OpenJPA witch look better to me than Hibernate that >>> I used to use. >>> >>>> Or is anybody here >>>> using it with apache wicket and wicket custom sessions? >>> Is that linked to technical param you would like to pass to all >>> service methods ? >>>> >>>> And what do you think about this http://jabsorb.org/ ? (The title is >>>> misleading, it contains json-rpc implementation and some JS code to >>>> talk with, for me unneeded). >>>> >>> If you or others, are ready to use the current version of JavaRPC2 >>> (should we call it like that ?) I'm OK to give it right now. >>> The only thing I would warn is not on stability, maybe performance >>> witch I didn't try but API stability. Durring the future rewrite, >>> it'll probably change it, maybe a lot. >>> >>>> Thanks >>>> - Petr >>>> >>>> 2009/9/17 Jean-Baptiste BRIAUD -- Novlog <[email protected]>: >>>>> Hi Petr, >>>>> >>>>> I start using JavaRPC and found that it works fine but need to be >>>>> refresh. >>>>> I would also a more modern way to set the attributes that should be >>>>> included/excluded from serialization. >>>>> Finally, if you need simple things, current JavaRPC is OK. >>>>> By simple thing, I mean, take one class, take all its attributes >>>>> via >>>>> and only via getters/setters, one instance is this class can >>>>> wake'up >>>>> in javascript world as it is and come back to Java world. >>>>> If you need to select some attributes only, not only by getters/ >>>>> setters but directly on attributes, had some special needs that may >>>>> not allow you to 100% accept JavaBean specification, then JavaRPC >>>>> is >>>>> to rigid. >>>>> >>>>> So, I had to modify it to fit our need and I feel I'll rewrite it >>>>> and >>>>> provide it as contribution if community find it useful, when I'll >>>>> be >>>>> out of my current taks. I'm late, lots of pressure, usual IT >>>>> things :-) >>>>> >>>>> Feel free to ask question on current JavaRPC, what are your needs ? >>>>> >>>>> On Sep 17, 2009, at 06:55 , Petr Kobalíček wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> how is status of JavaRpc in qooxdoo contrib (documentation is >>>>>> quite >>>>>> outdated)? Or, how other java rpc servers are people here using? >>>>>> >>>>>> Thanks >>>>>> - Petr >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Come build with us! The BlackBerry® Developer Conference in >>>>>> SF, CA >>>>>> is the only developer event you need to attend this year. >>>>>> Jumpstart >>>>>> your >>>>>> developing skills, take BlackBerry mobile applications to market >>>>>> and >>>>>> stay >>>>>> ahead of the curve. Join us from November 9-12, 2009. Register >>>>>> now! >>>>>> http://p.sf.net/sfu/devconf >>>>>> _______________________________________________ >>>>>> qooxdoo-devel mailing list >>>>>> [email protected] >>>>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Come build with us! The BlackBerry® Developer Conference in SF, >>>>> CA >>>>> is the only developer event you need to attend this year. Jumpstart >>>>> your >>>>> developing skills, take BlackBerry mobile applications to market >>>>> and stay >>>>> ahead of the curve. Join us from November 9-12, 2009. Register >>>>> now! >>>>> http://p.sf.net/sfu/devconf >>>>> _______________________________________________ >>>>> qooxdoo-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Come build with us! The BlackBerry® Developer Conference in >>>> SF, CA >>>> is the only developer event you need to attend this year. Jumpstart >>>> your >>>> developing skills, take BlackBerry mobile applications to market and >>>> stay >>>> ahead of the curve. Join us from November 9-12, 2009. Register >>>> now! >>>> http://p.sf.net/sfu/devconf >>>> _______________________________________________ >>>> qooxdoo-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in SF, >>> CA >>> is the only developer event you need to attend this year. Jumpstart >>> your >>> developing skills, take BlackBerry mobile applications to market >>> and stay >>> ahead of the curve. Join us from November 9-12, 2009. Register >>> now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> qooxdoo-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart >> your >> developing skills, take BlackBerry mobile applications to market and >> stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
