Re: R: R: [Phrame-devel] Phrame and Log4php

[Alex <ale...@ya...>]

Hi Sergio,

> >> I am working on two others things:
> >> - application configuration (with a web.xml
> file),
> >> used instead of modification of the
> WEB-INF/options.php file.
> 
> > we should consider building one config file for it
> as well.

> In struts I see 5 files (struts-config,
> tiles-config, validation,
> validation-rules and web-app), plus log4php: seems
> to be too much :-)

Hmm, Log4Php would indeed be a stand-alone config, as
it is a stand-alone library. 

As for the phrame-config, web.xml and the validation
things, I personally wouldn't mind putting that in one
config file. We want to minimize overhead here. 

The way Struts does things, is not necesarily always
the ideal solution. Java caches these things, if I am
not mistaken, and we don't as yet. Also, with Java
there is more need for XML-configs then with PHP. If
for every page-hit we need to parse 5 xml-files...

> Well, we must work in integration, but heach package
> must work also alone
> (as is now for log4php, adodb and smarty) and
> integrated by phrame.  I think
> the goal is to use a config file driven setter,
> instead of webapp
> options.php

A config file driven setter? 

> Now you use XML config in XMLMappingBuilder::get(),
> which load data with
> private methods, then discard the loaded xml tree.

I implemented it following the builder pattern. After
building the object, it does indeed discard the XML
stuff.

> My proposal is to build a PhrameCreator object:
> 1) the contructor read phrame-config.xml and set all
> define using specific
> context-param

The usage of define vs $options array has not yet
completely decided upon. I've talked about it for a
while with Jason and Arnold. Both have plusses and
minuses. We should talk about it some more. The
$option array should not yet be discarded as yet.

> 3) method for creating an adodbconnection (using a
> specific context-param
> for dsn)

Pieter was working on a data source thing for Phrame.
You might want to talk to him about this particular
point.

> 5) create a controller (using an
> ActionController::create()); the logic for
> caching should be transferred here, 

I agree, and I did as such. Problem is, you can't
subclass static methods. So, it's not an end all
solution. I ended up putting some code back in the
phrame.php (or index.php depending on versions) 

> because the
> creator must decide if
> create a mapping to be passed to the controller
> creator.

Well, I personally see no problem in configuring this
thing in the phrame/index.php. You can't configure in
an xml file if you want to use an xml file for config
things... In my proposal 2.1 Struts controller code,
you can either pass an ActionMappings object or have
the Struts controller automatically load the XML-file.

For the 5 or 6 examples I posted with that controller
that worked well.

> >> - authentication & authorization (like jaas), 
> 
> I seen your examples.  But should be "pluggable"
> with the desired strategy
> (specified in configuration file): 

Absolutely. I didn't get to making it generic. But I
wrote some routines that will certainly be some good
for reuse. For example the role checking and the XML
parsing modifications for users and roles. The
authorization part could be good starting point. How
you actually do the authentication should indeed be
rewritten. 

Kind regards,

Alex

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com