Architectural considerations on WLPS JSP tags

Question

Hello,
I'm now looking at the WLPS (2.0) examples, more specifically to the
BuyBeans example.
I have experience in developping web applications using J2EE
(servlets-jsp-ejb).
Something in the bean example is very disturbing to me : I've always tried
to maintain a clear separation of concerns between the different blocks of
an application, namely business logic, control and view. Those of you
familiar with it will have recognized the MVC (model-view-controller)
paradigm.
And in the bean example, I see the JSP full of tags mixing the view and
controller roles, even some of business logic sometimes.
So my question is : is there a way of using the personalization/commerce
server while maintaining the separation of roles described above? And if so,
is it an efficient way of working or does it create too much overhead from a
development time point of view?
I hope I'm being clear enough. Please ask for clarifications if needed.
Thanks in advance for sharing your opinion on this subject
Nicolas

Answer 1

Nicolas,
I agree that the integration between PS and CS is not as tight as it could
be and we are working (hard!) on improving this right now. There are options
however, and a limted integration between the two is possible. The
DestinationDeterminers are pluggable so it should be possible to write
custom code to do both. As you say, this may not be an option on a tight
deadline if you need to deliver immediately.
Incidentally, the main reason we did not want to replicate the "old"
BuyBeans demo was that it contained a lot of code that was specific to the
BuyBeans site and look and feel. We wanted to create a "template" site that
was a much better starting point for users to customize.
I appreciate your comments, and I think you will be very pleasantly
surprised with coming releases which address things like graphical webflow
definition and move PS (and Portal) onto the Webflow model.
Sincerely,
Daniel Selman
Nicolas Lejeune <[email protected]> wrote in message
news:[email protected]...
Thank you Daniel,
I actually had a good look at the commerce server 3.1. You're right,
pipelines and
webflow are useful things, although the latter is a bit tricky since there
is no editor yet.
The big problem with version 3.1 is that the perso. server and thecommerce
server
are not compatible anymore. I guess that's why the buyBeans example isout,
and
the new commerce example (the catalog) is not a portal.
They are incompatible because with the PS, everything has to be sent tothe
Portal
Service Manager, and with the CS, everything has to be sent to the webflow
manager.
It might be possible to somehow combine them, but it's certainly not
straightforward
and we don't have time to play around in my actual project. I asked a BEA
instructor
about it but he had no solution.
Since the portal look&feel was a priority to us, wo we decided to drop the
CS, and
use only the PS.
Any comments on this subject ?
Nicolas
"Daniel Selman" <[email protected]> wrote in message
news:[email protected]...
Nicolas,
MVC considerations were a big part of the rationale behind the Webflow
and
Pipeline architecture used in WLCS 3.1. I suggest you take a look at the
latest release, which does a much better job at handling this (complex)
topic.
Sincerely,
Daniel Selman
Nicolas Lejeune <[email protected]> wrote in message
news:[email protected]...
Hello,
I'm now looking at the WLPS (2.0) examples, more specifically to the
BuyBeans example.
I have experience in developping web applications using J2EE
(servlets-jsp-ejb).
Something in the bean example is very disturbing to me : I've always
tried
to maintain a clear separation of concerns between the different
blocks
of
an application, namely business logic, control and view. Those of you
familiar with it will have recognized the MVC (model-view-controller)
paradigm.
And in the bean example, I see the JSP full of tags mixing the view
and
controller roles, even some of business logic sometimes.
So my question is : is there a way of using thepersonalization/commerce
server while maintaining the separation of roles described above? Andif
so,
is it an efficient way of working or does it create too much overhead
from
a
development time point of view?
I hope I'm being clear enough. Please ask for clarifications if
needed.
>>>
Thanks in advance for sharing your opinion on this subject
Nicolas