Hi Christian, This all sounds promising and it's not that I don't want to do the work, but I'm very pressed for time so if I explain what my classes do (at least the simplest one) could you give me a hint as to which part of Avalon I should study and/or "copy" from (i.e. copy and adapt)?
Here we go: what I basically have/need is the following: Objects passed around are "persons", i.e. a set of data belonging to 1 person. I create a (Corba) connection to the server (I have 2 of these) by providing a servername, namingservice address and some extra settings. I can pass several types of queries which result in data that are processed in a separate class to something that is more easily manageable by Cocoon. I get stuck when trying to convert the modified XML (through a Woody form) back into a structure readable by the server for storage. The following situations need to be handled: 1. if data is not modified, don't store 2. if data is modified, store, pass on success or failure 3. if new person's data is stored, check for duplicate, pass on success or failure In all cases success or failure should be indicated on a page that also displays the (updated) person's details. When writing this I realise this looks a lot like access to a regular database, so maybe you can tell me which classes I can study best? Thanks and bye, Helma > >>-----Original Message----- > >>From: Christian Haul [mailto:[EMAIL PROTECTED] > >>Sent: Monday, 16 February 2004 13:51 > >>To: [EMAIL PROTECTED] > >>Subject: Re: Best practice for "database" manipulation? > > > > > >>Other than that, my advice is to put your database access > into a java > >>class (better: Avalon components) and access it from flow. If > > > > > > This sounds like a good idea. I've been studying several > *.js files and I > > get a general idea of how it should work, but...what do I > get from building > > my classes into Avalon components and... what should I do > to convert my > > classes into Avalon components? I cannot afford to spend a > considerable > > amount of time to study yet another framework. > > You gain flexibility and if your classes hold state or configuration, > the Avalon component manager (soon service manager) manages > them for you. > > The pattern is to define an interface as contract to fulfill and > configure at startuo time the "right" implementation to use. Avalon > provides a number of lifecycle interfaces that allow the manager to > setup your components. E.g. give access to other components or pass > configuration data to them. It also manages concurrent access to a > component by instantiating additional ones, pooling instances or > sharing instances across thread depending on the marker on > the component. > > Cocoon is based on this principle and whenever you access a generator > for example, the Avalon component manager directs the play. > > If your classes don't have any such requirements, converting a normal > class to a component is to > a) create a corresponding interface > b) add a ROLE constant to the interface as individual name > c) declare your component in cocoon.xconf using > <component-instance..../> > d) access the component from other components that implement the > "servicable" interface. (your component gets a reference to its > managing component manager) > e) use manager.lookup(YourInterface.ROLE) to access it > f) release the component when done using manager.release(myComponent) > > d) does not apply for flow > e+f) there are methods on the "cocoon" object in flow for this. > > Avalon is very easy to program to. > > Chris. > > --------------------------------------------------------------------- > 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]
