About bug tracking and xBug

[Philippe Lavoie <ph...@cactus.ca>]

Hi,

I'm not sure if XSP supports the xspBeans yet, but I think that you should
elliminate
most of your 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). 

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

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.

Those are only my feelings, don't get too emotional about them :)   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
	- 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.

Anyway those are my advices, feel free to take them to your nearest
wastebasket.

May the source be with you

Phil

RE: About bug tracking and xBug

[Ricardo Rocha <ri...@apache.org>]

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