[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cgiapp] load_tmpl() question.


Sorry, now to the whole list...


From: Stephen Howard <suppressed>
> > I disagree. I think that by adding new methods to C::A you just clutter it up.
> > We could end up with hundreds of new methods that just act as interfaces to
> > different contructors/methods of other commonly used modules (T::T,
> > CGI::Session, D::FV, etc). I find that 'explicit invocation of external
> > modules' makes the code very easy to follow since you know exactly where to
> > look for documentation about what is happening. Instead, if C::A implements a
> > interface (which would add one more method call to your object creation
> > costing you .00000001 sec) to another object, then the C::A docs would try and
> > explain things that that particular modules documentation explains.
> 

> I actually don't feel that making a routine polymorphic adds discernable 
> bloat.  Then again, I'm a TT guy, and don't use load_tmpl

I don't feel that making a method polymorphic adds bloat either. What I was
objecting to was added a new method ('load_tmpl_scalar_ref()' I think). I also
think it unnessesary to try and rewrite load_tmpl() to handle every possible
way that H::T->new can be used. I think it was meant as a very simple
interface for the simplest case. 

I too have used scalar refs, etc. If we just treat load_tmpl as a very simple
interface to H::T, then maybe we can decrease the coupling between H::T and
C::A. Don't get me wrong, I am a big fan of H::T and use it exclusively. But I
think that it might be hindering others from adopting C::A. I guess my real
question is 'Why should C::A reimplement H::T's new()'.



> > Instead of this, I think we should resume the discussion we had a few months
> > back about including some sort of plugin/registry/cleanup functionality to
> > C::A. Then when someone else requests this same kind of feature (just an
> > interface to another module) it can be implemented in it's own C::A::Plugin
> > style and not clutter up C::A itself.
> 
> I'm afraid my own efforts on this got a bit derailed with my late 
> shipment of Tuits.  The code for Application::Pipeline is in pretty good 
> shape though, and I hope to get back to getting it into CPAN shortly.

I think I may have forgotten a little of our discussion previously on this
issue, so forgive the perhaps obvious question. Is A::Pipeline designed so
that C::A will inherit from it and register it's own events in that pipeline?
Or is there some other purpose for it?

Michael Peters
Venzia


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed


Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.