Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 15761 invoked from network); 14 Sep 2000 19:39:41 -0000 Received: from adamo2.supereva.it (HELO mail.supereva.it) (195.110.96.109) by locus.apache.org with SMTP; 14 Sep 2000 19:39:41 -0000 Received: (qmail 16038 invoked from network); 14 Sep 2000 19:39:14 -0000 Received: from unknown (HELO ARES) (151.35.2.149) by mail.supereva.it with SMTP; 14 Sep 2000 19:39:14 -0000 Message-ID: <00af01c01e83$8ba79a60$ac022397@ARES> Reply-To: "Nicola Ken Barozzi" From: "Nicola Ken Barozzi" To: References: Subject: Re: C2: Uploader needed Date: Thu, 14 Sep 2000 21:39:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N From: "Per Kreipke" > Well, not exactly. Of course there needs to be storage but I specifically > want to use Cocoon to avoid choosing a particular one. Maybe an example will > help. > > Suppose the user authors some data in an HTML using an input form (POST). > The HTTP request comes in as a POST and I grab the text they sent. Now I > want to put it into a target data store. The address of the target store > comes from the user's session let's say. So, the final XML snippet might be: > > > http://my.storage.machine/items/insert > Today > Bill > The NYSE went tumbling down. > > > I then want to route this snippet to the storage server. I might even want > to send a copy somewhere else (say, an indexer or email gateway). Each > internal server would know what to do with the data. SQL servers would > insert the data, file stores would save the snippet to disk, etc. I'd then > be able to redirect the storage to different servers as needed, but the > _data_ (not function) contract would remain the same, no need to recode the > middle layer. > > The nice bit would be that each step of the task can simply be a transform > (or multiple ones). In the example above: > > - transform HTTP request to XML request format using XSL > - combine request XML with session data (XML?) to build message format above > - fork (and optionally) transform the message to the indexer > - optionally transform the message format to storage server instructions > (e.g. XQL command) and send to the storage server. > > Per. > > p.s. Can you say MS BizTalk anyone? Sounds like the proposal of XForms I made some time ago can come in handy, even if in part it is repeating thing done. Maybe it can help to put things in perspective. Since I'm lazy I will shove it in as-is. ;-) Anyway, it basically says that there has to be a "framework" (not really so, since it's just a way of using Cocoon) that is capable of "inverting" the data stream. Here I talk of forms, other methods are sub-systems IMHO, because form presentation to the user may be not required. More comments at the end... Some time ago I wrote: > > I would like to take this mail as an opportunity to discuss about the use of > forms in Cocoon, and about how it can be done. > > I know that others have started similar discussions and implementations > in the past, and I apologise beforehand if I repeat things and are not > aware of some past conclusions. > This is my contribution to the subject, I'm waiting comments. > > The goal is setting up a new form system that integrates well with > the notion of content-view separation. > The system has to be as flexible, simple and extensible as possible. > The starting point is the XForms specification draft on the W3C site. > > First of all: what is a form? > Even better: what is a form system? > > A form system is a way of inverting the data stream: the data comes > from the client. > A form is a way of presenting the "questions" that answered create the > data sent to the server. > > The verb "presenting" suggests that forms are > a view... so they need stylesheets (1), one for every client type. > Forms are not only style, because they are also content like any other > content. You need xml (2) to drive a stylesheet. > Form data needs to be checked for correctness, so you > need a validator (3). > The validator validates against a schema (4). > Then you need to do something with the data (5). > > Looking at the XForm spec you can see that (2) is html, svg, etc. > We need xml that gets mapped dynamically to those formats. > > The following is a scheme of how things can work and what is needed. > I made two versions hoping all can see it ok. > (this drawing is for fixed space fonts). > > 4) ----------------------- > XML Schema --------| schema file ref | > | | > | | > | | > | | > | | (2) > | | > | | > | | > | | > ----------------------- > | > ----client input ----------| > | processor (3) > | | > XSL(1)------yes-------error in validation? > | > no > | > ----------------------- > XML Schema --------| schema ref | > | | > | | > | | > | | > | | > | | > | | > | | > | | > ----------------------- > | > | > (5) > > > (this drawing is ok in Outlook). > > (4) ----------------------- > XML Schema --------| schema file ref | > | | > | | > | | > | | > || (2) > | | > | | > | | > | | > ----------------------- > | > ----client input ----------| > | processor (3) > | | > XSL(1)------yes-------error in validation? > | > no > | > ----------------------- > XML Schema --------| schema ref | > | | > | | > | | > | | > | | > | | > | | > | | > | | > ----------------------- > | > | > (5) > > Let's see what is missing now: > (1) need all the stylesheets for all clients. > (2) We need to define general tags for inserting references to the > schema in the xml. They are needed by (1). > (3) Need a processor that uses a schema validator and validates. > (4) XForms schemas are different from normal schemas. > We need an XSL that maps between the two. > (5) I think basic ones are needed, like an SQL insertor or XML insertor > (there are implementations, we just have to tweak them). > I think a redirector is very important. > > As you see I haven't discussed about how the client interacts, if he > sends xml or single nodes. I think that it is not that important for > now as long as the data gets to the server... > Sending Xml is important when the amount of data sent is not known > beforehand (arrays). I needed it myself once but imho it is 1% of 90% > of forms. > > Here transactions are not discussed; I think that they should be taken > care of in (5). Sitemap was not there finished ATTOTW, so no I think that the loops and decision in the flow should to be sitemap based. Simply put, the logic part, meaning the business logic flow, has to be done by the sitemap. Part 5 is where FP taglib should be (XML changing)[now it does other things that should be made usable to others IMHO], but also ESQL (DB updates), XML posting (this case), mail delivery, and all sorts of stuff. Transaction commit-rollback though is not there... would be cool IMHO. Comments... nicola_ken Nicola Ken Barozzi - AISA Industries S.p.A http://www.aisaindustries.it/ Via Leonardo da Vinci,2 Ticengo (CR) Italy Research Activity: Politecnico di Milano - Dipartimento di Meccanica Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy) > > I think what this is leading up to is the need for a back-end > > data store -- > > without it a method to upload would be rather useless. A worthwhile > > endevour to be sure. There are XML object stores available. I would > > familiarize myself with those and choose one based on suitable licensing, > > architecture, and support. > > > > > > > > At 11:56 AM 9/14/00 -0400, you wrote: > > >I was asking about something similar on the '[C2] Access Control Needed' > > >thread. Similar to upload of files would be the ability to input XML > > >document into the system from outside via POSTs. Specifically, > > I'm thinking > > >of having Cocoon handle XML-RPC requests. > > > > > >XML-RPC uses a "text/xml" POST HTTP request to send a XML payload > > >(containing function name and params) to the server which then > > executes the > > >referenced function and ships back another XML payload > > containing the return > > >code/contents. > > > > > >An example use of this is to add messages to discussion groups or posting > > >images, etc. > > > > > >I asked in the other thread whether the sitemap would allow XML > > transforms > > >in the input direction. I didn't get a clear answer [or failed > > to understand > > >it :) ]. > > > > > >Would this be a similar transformer/whatever? > > > > > >Per. > > > > > >> -----Original Message----- > > >> From: Matthew Langham [mailto:mlangham@sundn.de] > > >> Sent: Thursday, September 14, 2000 8:52 AM > > >> To: cocoon-dev@xml.apache.org > > >> Subject: C2: Uploader needed > > >> > > >> > > >> We need to integrate the possibility of uploading files into > > Cocoon and I > > >> have been thinking about how best to do this - but then I thought hey - > > >> maybe someone has already done this. > > >> > > >> At the moment we are considering an "UploadTransformer" which > > >> would grab the > > >> uploaded file from the HTTP stream and write that out to wherever.. > > >> > > >> Comments or "done that"s? > > >> > > >> Matthew Langham > > >> > > >> -- > > >> Open Source Group sunShine - Lighting up e:Business > > >> ================================================================= > > >> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn > > >> Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de] > > >> ================================================================= > > >> > > >> > > >> > > > > > > > > > > > > > > >