Hi Petr, On Sep 19, 2009, at 00:30 , Petr Kobalíček wrote:
> Hi Jean, > > thank you for comments and for rpc preview, I will take a look. > You're welcome. > 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). Sorry but I don't see the logic behind. Why Wicket because it is an administrative part of an app ? I guess the admin part it totally deconnected in term of object and behavior, so it could be done with some differences, for example without wicket. > 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). OK. > > 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 :) > Yes, wicket is currently one of the best old school web framework but why using old school stuff if is not usefull and needed ? You don't need view on your admin app since qooxdoo is the view, isn't it ? So what will be the added value of wicket on that admin app ? I feel like in your case wicket or any other web framework will just make things more complicated. Basically, where qooxdoo is choosen, no more (bloated) web framework is needed ! All that is replaced by a simple class that implement RemoteService, an empty interface, can you find a simpler web framework somewhere ? And simpler doesn't only mean better abstract things like software architecture, it also has concrete advnatages : * less code to write * less bloody xml config files * less bug * less time => more pleasure, better apps :-) > 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. If you have strong deadlines and if you didn't already found bad things in Hibernate, stick to it. One good reason to leave Hibernate is its incapacity to save time by providing your object back to you. As soon as you nedd request it come back to you with collection of hashtable ... so bad ! OpenJPA come back to you with collection of your Object : List<Person> for example. So the job is done by OpenJPA, not by you. This is not just a details but a key feature an ORM (Object Relationship Mapper) has to do for you. Else, you'll lose your time to convert that hashtables into instance of Person : it should not be your job. Another point is FetchPlan but I don't have time to explain all the details. For myself I would not be able to go back to it since I tested OpenJPA :-) Anyway, don't underestimate the cost of that change even if it is more powerful. As a developper, it can be very frustrating to explain it will be better without having something to show :-) > BTW: Are you using Spring? No because of KISS pattern. This also make things more complicated for no added value. It make their users writing XML rather than programing and this is a very big antipattern. > > 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 > ------------------------------------------------------------------------------ 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
