Hi, Is there an updated version of this document (Extending Tuscany) that reflects the current state of the trunk? Most of the classes in the models shown are nonexistent today. Is the whole programming model depicted here irrelevant? thanks snehit
On 4/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pamela Fong wrote: > If I choose to use EMF to generate a model to represent my extended SCDL > schema, I would also need to generate EMF model to represent > sca-core.xsdsince the binding schema extends from the core schema. So > I would end up > packaging two generated packages within one binding extension. Someone > else > comes along adding extension to sca-core and using EMF to generate the > model > code, also needs to package the core and the extended packages. How do > things co-exist in the long run? Or do we just assume all generated core > packages should be identical and thus it's ok to have it multiple > times in > the classpath? > > On 4/10/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >> >> Pamela Fong wrote: >> > Hi, >> > >> > I read the article "Extending Tuscany by contributing a new >> > implementation / >> > binding type" by Raymond and Jeremy. Got a question about the >> > definition of >> > ModelObject. The example in the article is a very simple java >> bean-like >> > object. This is fine if all we have to deal with is some simple >> > attributes >> > in the extension. If the binding requires complex SCDL model >> extension, >> > defining the ModelObject by hand may not be the best choice (let's say >> > one >> > could have mulitple layers of nested elements and arrays etc.). One >> > obvious >> > alternative would be to generate some model code based on the >> extension >> > xsd using EMF. However, since the binding's xsd extends from >> > sca-core.xsd, >> > generating model code would require the core model, which doesn't >> > exist in >> > Tuscany. What would be the recommended mechanism to define the >> > ModelObject >> > in this case? >> > >> > -pam >> > >> >> Hi, >> >> ModelObject does not exist anymore in the latest assembly model in trunk >> (now under java/sca/modules/assembly). The assembly model is now >> represented by a set of interfaces, so you have the flexibility to >> implement your model classes however you want, without having to extend >> a ModelObject class. >> >> You can choose to use EMF or another suitable XML databinding technology >> to implement your model classes or, probably simpler, just create plain >> Java classes that implement the model interfaces. The only requirement >> for a binding model class is to implement the o.a.t.assembly.Binding >> interface. Then, if you choose the "plain java class" option, to read >> the model from XML use StAX as we've done for the other bindings (see >> java/sca/modules/binding-ws-xml for an example), it is actually pretty >> easy thanks to StAX. >> >> Hope this helps. >> >> -- >> Jean-Sebastien >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > Right, if multiple extensions choose to use a specific databinding or modeling technology for their models they'll need to coordinate if they want to share some code. I would recommend to try implementing your model using plain Java classes first, at least this way you can share more code with the other model modules from Tuscany. -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
