Hi Christian ,
Thanks for the initiative in replying with your thoughts. Please see inline
for my comments.
Let the thoughts flow.
regards,
Praveen
-----Original Message-----
From: Christian Bollmeyer [mailto:[EMAIL PROTECTED]
Sent: Monday, October 31, 2005 3:29 AM
To: Struts Users Mailing List
Subject: Re: Is there an abstract meta-model of Struts ?
Hi,
your thoughts are quite interesting, but unfortunately I don't know about an
official MOF and kind of doubt from my own experiences Struts development
can succesfully be formalized that way.
[Praveen]
===============================================
I am only interested in meta-model, meta-definitions and formalization of
the overall structure of Struts - and not formalization of code written by
individual developers. The developer is free to implement code in the way he
wants to as long as he adheres to ** a well known formal model ** that's
defined with the relevant syntax and semantics.
===============================================
For instance, many people still think quite differently about the 'M' part;
there is no 'official' rule what 'Model' actually means; if Actions (or even
Forms!) may be considered part of the Model an so on; I've seen quite a lot
in this direction.
Struts is largely open to architectural decisions of this kind.
Struts provides a standard way for handling web input, based on the
existence of a central 'request processor' servlet that delegates the
information flow to Action implementations that do the actual work,
determine the outcome and return it to the client somehow, plus the ability
to manage the exact details declaratively via struts-config.xml and web.xml.
[Praveen]
===============================================
You have defined the meta-model partially in the above sentences - although
in prose. Getting the meta-model of your prose description would be a
logical next step. MOF can be utilized in such an effort.
For ex:
Step-1: Define using MOF the 3 most important base modellable entities in
Struts ie 'Model', 'View' and 'Controller' as a starting point.
- This can be enriched and more details like validation, security etc may
be added.
- Other important entities may be considered for Modeling later
Step-2: Defining the relationship between the Model and View, Model and
Controller, View and Controller.
- These relationships are expressed based on the nature of interaction /
no-interaction between the modeled entities
Step-3: Publish this information to all as MOF constructs / artifacts
Benefits: As a result of such an exercise, anybody who follows the above MOF
constructs / artifacts would be ** bound ** to the overall framework and
deviations would not be allowed. The actual implementation of the
java/c++/c# code/classes/interfaces for the 'Model', 'View', 'Controller'
and other important Struts entities is decided by the end
developer/architect.
- All developers would be forced to have code that identifies and realizes a
'Model', 'View', 'Controller' etc. He may choose as per his discretion to
write code where Forms and ActionClasses are the 'Model' for instance.
- All developers would be forced to have a structured/defined
communication/relationship between the 'Model', 'View', and 'Controller' (
and other important entities like validation etc)
- Removes ambiguity from the developer's mind on where ** stuff ** needs to
go into.
- Reduces the Struts learning curve and training efforts for newbie's since
a formal referenceable model is present.
- Makes migration of application code from one version of Struts to a higher
version much easier.
- Organisations can be allowed to extend and create their own specific
Struts-like meta-models/frameworks incase they are interested in specfic
parts of Struts.
My aim is make my Web Application development efforts as quick, simple,
maintenable and standards compliant as possible.
Well, these are my thoughts. Your feedback is welcome.
===============================================
But it does not enforce a formal coding or application design paradigm, and
that's probably very wise, as Struts is a protocol-near, 'down-to-earth'
framework by nature, originally aimed at providing a best-practice solution
in a spot that had been left dark by the J2EE specs. In effect, Struts is a
different kind of animal when compared to things like WebObjects, Tapestry
or JSF which were driven by different design goals.
Perhaps Craig can shed some more light on this.
-- Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
