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
|