cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ricardo Rocha" <rica...@apache.org>
Subject RE: About bug tracking and xBug
Date Thu, 20 Jan 2000 18:11:57 GMT
On Jan-20-2000 Philippe Lavoie wrote:

> I'm not sure if XSP supports the xspBeans yet, but I think that you should
> elliminate most of your business logic from XSP.

The bean support library hasn't been developed yet. It will be available
"anytime soon now" (TM). Note, though, that this library is _not_ an
integral part of XSP's mechanism for business logic abstraction. I see
it more as a convenience, one-size-fits-all mechanism for gluing your
components with XML content. In addition to XBean, XSP also allows
for other idioms closer to the XML spirit, so to speak.

XSP pages should always avoid embedding logic. As much as possible,
logic should be encapsulated in dynamic tags and stored in XSP libraries.

Furthermore, logic thus "hidden" in libraries should, as a rule, rely on
non-XSP, independently developed Java Beans. From this point of view,
yes, one should eliminate most business logic from XSP.

> Yes it means you are not  using the SQL XSP processor, it also means that
> people using your system can  configure things without affecting the vital
> parts (the table structure of your DB for example).

Hmmm... What I stated above implies that your XSP libraries should _not_
directly do things like table-specific, low-level Jdbc access. While this is
possible, it violates context separation.

Still, you _can_ use the SQL XSP processor. In XSP's layered processing
model you can preserve abstraction at the page and library level, while
generating efficient code.

> Stephano (or others) will correct me if I'm wrong, but XSP doesn't remove
> the need for real classes, real Java beans, etc.

Of course not! I'd say XSP _relies_ on them. This is a rather unexpected
comment: why on Earth should XSP remove the need for real classes?

> It is just an easy way to access them and make them availble from your UI.
> XSP abstracts the UI problems from your application by allowing you to
deal
> with the UI integration in an easy way.

No!! XSP is _not_ a UI-oriented facility!

XSP is a dynamic tag processing language. It's meant to support
semantically-oriented vocabularies containing dynamic elements
whose contents are provided by logic.

XSP does _not_ focus on the user interface, although it can
address it. UI is best handled by XSL transformations.

Given an application domain (as represented, for example, in
UML class or state diagrams or entity-relationship data models)
a semantically-oriented vocabulary is derived that can express
all valid "phrases" expressed in terms of the entities and
relationships making up the universe of discourse.

This vocabulary is embodied in a DTD/XSchema where noun tag
names represent [static] entities and relationships, while verb tag
names represent [dynamic] operations (methods, in Java
parlance) defined on such entities.

Given such structured vocabulary, non-programmers familiar
with the application domain at hand can author XML documents
containing meaningful expressions in the language defined
by the underlying data model. This, btw, is what XML is all
about: an extensible markup language.

XSP's realm is that of _dynamic_ elements: those representing
logic-based operations that yield results belonging to the
static vocabulary.

Resulting (static) markup can be later processed to yield
a syntactically-oriented presentation, such as HTML. This
is the realm of XSLT. It is here that you deal with the UI.

> My feeling is that a strategy which focuses on the technology
> (XSP, Cocoon) and not the problem (bug tracking) will not be as
> reliable and usable as one which treats  XSP and Cocoon as tools
> that have a proper role in an overall design.

Here we agree completely: any correctly designed system is
defined in terms of the problem space, not in terms of the tools
used to implement a solution.

That's why I'm proposing a formal methodology that captures
the semantics of the application domain but in a way that is, yes,
readily translatable into the Cocoon toolset.

> Those are only my feelings, don't get too emotional about them :)

No offense taken, my friend. This sort of discussion enriches us
all.

>  Anyway, from the xBug discussion I feel that the focus is not at
> the right place. I'd start xBug by  doing the following:
> 	- look at existing bug tracking system
> 	- Find their strengths
> 	- Find their weaknesses
> 	- Find solution to the weaknesses
> 	- Find a design that uses the strengths and the new solutions
> 	- Define your schemas (or DTD) that are used by your new design
>             These schemas define the data structure of your application,
not
>             how you access or modify it.
> 	- Have a hearty discussion on the subject with friends, family and
>             dog

Agreed. I feel this is an interesting formulation of the above mentioned
methodological proposal from a strategy perspective.

> 	- Have one dude start on the business logic, and another on the UI
> 	- The UI guy will tell the business logic chick how it wants to
>             access the application. In other words, the XSP tags needed to
make the
>             UI rock. These tags will hide as much as possible the
implementation
> 	 details, it will make the stuff needed easy to do while allowing
> 	 complex things to done if needed. UI needs and business needs *are*
>            different.

Here we differ again: XSP's role is not restricted to the UI. If your
dynamic tagset is correctly designed, then XSP will make it simple to
express content in a way amenable to UI presentation. But this doesn't
mean UI is the whole XSP raison d'etre...

Ricardo


Mime
View raw message