Rafal Krzewski wrote:
>
> Raphael Luta wrote:
>
> > > Initializing other subsystems is a very nice 'service' itself, isn't it?
> > >
> > > Move your ininitalization code from Layout into this wrapper service
> > > (JetspeedInitService?) and avoid creating the subclass alltogether.
> > >
> >
> > In that case, I may mis-understand what you're doing with services.
> >
> > My understanding of the Turbine service system is that it provides a way
> > to register initable singleton components that can be accessed from
> > other classes and provide well defined functionalities, usually through
> > an interface declaration independant of the actual implementations.
> >
> > The typical service package pattern being:
> > <service>/
> > <service_interface>.java
> > <service_implementation>.java
> > <static_service_accessor>.java
> >
> > If this is a correct definition and the real intent of the service
> > framework, what is the point of a JetspeedInitService with an empty
> > service interface and which can't be used by any other classes ?
>
> In my opinion, methods that are implicitly called by the framework
> itself
> provide *a service* no less important that methods explicitly called by
> the application.
>
Not in the sense of the org.apache.turbine.services.Service interface, what
you describe is org.apache.turbine.services.Initable.
> > It's a hack in my book.
>
> Agreed, this is hack. But subclassing Turbine servlet is a *way* worse
> and uglier hack in mine.
>
Then your position can be summarised by :
- the Turbine subclass solution is bad because :
* this sets a bad example for other Turbine applications (you've not
yet given a reason of *why* it's bad practice)
[ Jon gave me a reason : it's error prone because it relies on super
calls for proper operation. I agree that it should be avoided.
]
* this creates unnecessary questions on this list by people who don't
understand very well the framework. I understand that it's a concern
for you.
[ There's definitely a lack of architectural documentation of Turbine,
many components are documented by no overview of the global framework
architecture and design postulates is given. This leaves each people
interested to figure out how the design is suppose to work and are
the design postulates based on tha available code. Don't blame them
if they can't do it, reverse engineering is difficult.
Before someone jumps in and says it's my itch to scratch: no it's not.
It's you (Turbine developers) who complain of improper use of the
framework
]
- the "empty service" is a hack and not a proper use of the Service interface
but is the only way available within the framework to implement this.
[ That's true. ]
My position is :
- implementing my init code as an 'empty service' is a perversion because it
violates the semantics of service framework
[ You agreed its a hack. If you don't believe it violates the semantics, please
give me a proper defintion of the service framework goal and design contracts
that is consistent with the existing codebase.
]
- my code is a functional equivalent of the TurbineServices.initServices() method
for initializing non-Turbine aware components. It should not exist within a
Turbine application so there's no point in incorporating it within the
framework but rather fix the non-Turbine aware components.
[ To quote you: "an engineer should strive to fix the real problems not the
symptoms" ;)
]
- given these arguments, I believe its better to implement the initialization
code outside of the Turbine framework (thus use a subclass of Turbine) and
blatantly say we are currently incompatible with the framework rather than
hide this incompatility hoping it will go unnoticed (as you effectively
advocate by using a service hack).
[ I believe the issue with this for you is that the incompatibility claim
will only be blatant for those who know the framework but may create
confusion for casual onlookers because Jetspeed is currently advertised
as an example Turbine application on your website.
I think it's a mistake to currently advertise Jetspeed as Turbine
compliant because this is not currently true (It was true in the early stage
of Turbine but the Jetspeed project has not followed until now all
the evolutions of the framework).
]
As you can see, I think we agree on most things but our conclusion is
different because our concern is different: you want Jetspeed to appear
Turbine compliant at all cost even when it's not true ; I want to properly
move the Jetspeed design to be able to be Turbine compliant in the near
future even if that means temporarily blatantly breaking the framework now,
because it's just a reflect of the real situation within the project code.
>
> My goal is not irritating you, but showing that the problem in Jetspeed
> can be solved without setting example of such a bad practice. If people
> start subclassing Turbine in their own applications, it will only yield
> more trouble for them and in effect to Turbine maintainers...
>
You don't irritate me at all. I even find quite funny that my arguments
are all about preserving the purity of the framework whereas yours are
"do whatever ugly hack you want as long as it doesn't show".
--
Rapha�l Luta - [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
