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]
>
>
