When I last played around with maypole ( pre 2.x ) I was a little dissapointed with some aspects of it, and the complexity of setting it up ( which have now apparently been addressed ). What it did do however, is give me the taste of just what can be done with a few lines of code and the "CRUD" philosophy ( present objects to the user that they can create, read, update and delete ) and the importance of seperating the CRUD application from the underlying framework.
Recently I've been contemplating the nature of things in relation to presenting a user interface to the client when html just won't cut the mustard. In a previous blog entry I was musing with the idea of exposing composite objects ( I can't think of a better word to indicate that its a set of objects joined by various relationships ) to web services, and using a java gui to edit the Data before shipping it back via webservices for a perl program to update the relevant tables in the database.
In an article entitled CRUD, only when you can afford it*, Maarten Mullender offers an interesting perspective, which seems to warn of some potential pitfalls with this approach ( I agree that it certainly isn't a magic bullet ), but this hasn't put me off, as my interest lies in using CRUD to accelerate application development, so that it frees up programmer time to spend on areas where it is required. In an ideal world, the intial build of a web service could be built entirely from a graphical representation of the data to be modelled, with the programmer moving in after this state to add the interesting bits where CRUD simply won't cut the mustard.
The impact of this transition on the design aspect of a project will be interesting though, with the seperation, interaction and representation of "CRUD" and "non-CRUD" elements of the system currently providing more than sufficient material for study and contemplation.
* I feel I must reference benjaminm's blog - web services, where I found this link.
Maypole 2
lilstevey on 2005-01-20T21:40:58
I believe so, and from what I hear it seems like an excellent piece of kit - however I feel that html, although a good medium, does not address the needs of the application(s) that I am looking to develop, hence the desire to look elsewhere.HTML v :Maypole 2 v SOAP v XUL
n1vux on 2005-01-21T00:14:25
Ahh! Yes, HTML/HTTP as the universal protocol leaves quite a bit to be desired (aside from Firewall pentetrability).If you come up with something as elegant as Maypole but based around WSDL and the other WS* standards, that would be way cool. (Not that the standard SOAP over HTTP is much of an improvement protocol-wise, but it decouples at least.)
Would a hypothetical Maypole::SoapLite extension, probably using WSDL::Generator and/or SOAP::WSDL do anything for you?
FYI, although I haven't used it myself, in the Java universe, the hot light-weight client-side toolkit is now XUL using Moxilla/FireFox browser. (tutorial). Think XML-based specification of TCL-like rich-but-thin GUIs that run in browsers? There's already a XUL::Node class on CPAN for server-side XUL in Perl. Other Perl-Xul connections are in progress, PerlXUL (advanced planning stage but dormant?)and Perl-Xul (list).
Your original posting's referenced articles' discussion of extensional CRUD versus intentional transactions is interesting. I need to think about this for a little web-app I'm planning to build to share updating the DB behind a query-only website. For that app, I probably have naturally optimistic concurrency -- no two people should want to update the same item at once -- so CRUD may be ok. Both CRUD and Transactional GUI+Engine stink if you have to stick-build every last screen or transaction; I'm looking for good easy tools. Maypole2 was the best I'd seen, but I need to re-think this, and quickly.
- Bill R
Re:HTML v :Maypole 2 v SOAP v XUL
lilstevey on 2005-01-21T14:24:51
A "Maypole::SoapLite" module would be most usefull ( although I imagine the dependencies would cover a large part of CPAN ) - Almost a Holy Grail as far as this project is concerned. In terms of my own development, I haven't yet decided whether its best to base this on Maypole, or base it on the theories that Maypole is based upon, I think a fair bit of R&D will be required - especially in WSDL and XML schema.
Your comment about the decoupling effect provided by SOAP is one of the reasons I am considering it - whilst I have no doubt that it is possible to develop complex apps using DHTML et al, the inherent cleanleness of having a seperation between UI and "application", and performing the communication over just one medium is a strong architectural argument.
I am aware of XUL, it sounds promising, although I haven't used it personally - I'll certainly have a look at the links you have sent when I get a few moments though, thankyou.
I'll be interested to hear of any solutions or strategy you come up with to get around the concurrancy issues - it sounds as if a simple incrementing "version column", with appropriatte checks as mentioned in the article might be a suitable compromise for your situation though?
You could quite trivially build a full crud UI using DHTML and javascript rpc/rest calls to the server, storing some state information in javascript and calling the server only for object persistence and retrieval.
I've seen it done over 18 months ago and we rebuilt it again from scratch. I think it would be as quick and easy as doing it in java.
You might not need java for crud
lilstevey on 2005-01-20T22:45:04
I totally agree that java would be a massive overkill for a simple crud only UI, however the design requirements, and the scale of the objects involved mean that an autogenerated UI isn't practical in this instance.
Perhaps starting again, taking onboard lessons learnt, but still using DHTML and javascript would offer some improvements, but I can also see some strengths ( if starting again ) in moving to a soap/java application to provide the UI ( rather than an applet ), and being naturally curious I'm keen to investigate further - Do you mind me asking the scale/ number of requests in the application you describe?Re:You might not need java for crud
TeeJay on 2005-01-21T08:54:45
It was an inhouse development version, but the full application we built and my friends have built again (over a weekend) were for very large scale systems.There is very little you can do in a Java client you couldn't acheive with a DHTML application.
Using a full webservice with a proper webservice client in the java client would be massive overkill - admittedly it would be less cumbersome and bloated than using CORBA but would be much heavier on the client than DHTML and XML/RPC.
Experiences of Java/soap
lilstevey on 2005-01-22T17:01:33
I was wondering if you had experiences of developing ( or attempting to develop ) java soap clients for use with perl web services - its not an area where I can find a great deal of material, and there seem to be a number of different approaches that one can take, so even a few words of experience would help out greatly ( Is there a particular set of libraries you found cumbersome, for example )?
