Re: [Cobold-developer] ideas and discussion issues

[<u....@gm...>]

hi *,

joern turner wrote:

> hello *,
>=20
> oliver charlet wrote:
>=20
>> hello cobolds,
>>
>> this is a short protocol about the dicussion we had yesterday:
>>
>> please feel free to correct and change!
>>
>> - separation of entities and behaviour
>> a basic pattern must be, to separate value objects and business logic.=
in
>> that way the datamodel can be modeled and implemented regardless of an=
y
>> semantic functions that use a lot of different entities. if the behavi=
our
>> would be inside the data objects, there would exist a very ugly=20
>> network of
>> close coupled objects.
>=20
> i would prefer to speak of logic or behaviour instead of just business =

> logic cause this is only a small subset of the code to be created for a=
=20
> full application. additionally this may be misleading cause the busines=
s=20
> logic normally is the part with the smallest potential of automization =

> in generative development.
>=20

agree. business logic is a quite fuzzy term with many different notions.
i'd too prefer to speak of behaviour. moreover i'd suggest to think of a
logical view layer which is created on top of the loosely coupled data
entities. behaviour is implemented on top of this logical view layer.
this may lead to complete decoupling of behaviour and data which is
desirable in terms of roundtrip engineering. additionally, the logical
view layer becomes subject to generation which seems desirable too.

>>
>> - back end design
>> given the fact, that Chiba is a fix component of the cobold architectu=
re,
>> the other major issue to think about is the creation of a back end=20
>> that fits
>> into the Chiba architecture. It needs tests and prototyping to develop=
an
>> efficient work flow to achieve 1) a well defined application framework=
=20
>> and
>> 2) a pragmatic software development process.
>>

just to be clear: i don't think that the current chiba architecture
should completely determine the cobold back end architecture. chiba is
targeted to become a flexible and generally usable component. when
difficulties arise during back end integration we have to think over
chiba's integration facilities too.

>> - GUI / navigation
>> since the GUI part of chiba as today is suboptimal in terms of easy
>> deployment of individual design, it seems to be a good idea to embed=20
>> chiba
>> inside another front end component like a cms or portal framework=20
>> (e.g. jet
>> speed etc.).
>> it is an unsolved issue to integrate a modular and flexible front end =

>> design
>> into xForms.
>=20
> i'd like to paraphrase this as: its not the goal of XForms to provide a=
=20
> presentation/layout facility - this is always the responsibility of the=
=20
> embedding language may it be XHTML, SVG or whatever. site- or=20
> application navigation shouldn't be handled with xforms; established=20
> technologies like portals or jsp are more suitable for this level.
>=20

again agree. since it is platform independent (or, at least, agnostic)
xforms - and therefore chiba - simply doesn't deal with layout. i don't
see an issue in integrating front end design into xforms, but in
integrating xforms with a presentation layer (which essentially has to
provide design facilities).

>>
>> - Chiba integration
>> being the first and only applicable software component of cobold,=20
>> chiba is
>> to be beta tested to develop a prototype for a complete system. first =

>> steps
>> will be to port the form4 jforce framework and adapt it to the chiba
>> controller.
>>
>> - Use Case XML / documentation
>> with the goal of a generative system in mind, there could be first=20
>> versions
>> of descriptive XML for UseCases, data model and business logic. Since =

>> form4
>> already has some experience in usecase implementations, a basic XML to=

>> describe the requirements to generate UseCase source code should be
>> developed in the next time.
>=20
> yes. very interesting. we could then take this as a testcase and build =

> XForms for it to get a feeling how this might fit together.
>=20
>=20
>>
>> - MDA / UML 2.0
>> since the generative view of software development is becoming more com=
mon
>> and is in the press constantly, it must be validated, how MDA=20
>> specifications
>> and UML 2.0 can be deployed to be a part of the cobold project.
>=20
>=20
> interesting to look at:
> - EMF (Eclipse project)
> - http://www.architectureware.de/ Open Source MDA tool / Generative=20
> Umgebung

regards, uli.

>=20
> Joern
>=20
>>
>>
>> so far for now...
>> :olliC
>>
>> -----------------------
>> oliver charlet
>> form4 gmbh & co. kg
>> rungestr. 19
>> 10179 berlin
>> fon +49 (30) 27 87 84 -0
>> fax +49 (30) 27 87 84 -10
>> oli...@fo...
>> http://www.form4.de
>> -----------------------
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Cobold-developer mailing list
>> Cob...@li...
>> https://lists.sourceforge.net/lists/listinfo/cobold-developer
>>
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cobold-developer mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobold-developer
>=20
>=20


--=20
Ulrich Nicolas Liss=E9