Re: [cep-dev] re: Some thoughts diagramed, I'm at it again

[Jackson M. <ja...@ja...>]

Marcus Whitney wrote:

> First of all... these ideas aren't new, not even to CEP discussion.  I 
> recall many convos where Jaxn suggested XSLT and having modules simply 
> return XML.  I'm just catching up, we work that way sometimes.

If I recall correctly, you talked me out of using XML/XSLT in those 
convos.  I guess now it is my turn.  We work that way sometimes too. :)

>
> The basic premise is that Modules are the one public universal API for 
> requesting activity from CEP.  Bootstraps can handle Module requests 
> differently (web request, XML-RPC, SOAP, REST, CEP Clean URL, etc.), 
> but the API itself would never change and never require any changes to 
> the transports to add functionality.

Agreed.

>
> Libraries are primarily for data access.  They could serve other 
> purposes... which brings a question for the spec.  Are libraries 
> really just namespaced method packages?  I'm starting to think I like 
> that instead of all the ORM, DataObject stuff.  Seems too involved for 
> our spec, but anyway....

I am starting to think along the lines of  "Business Objects" to  
perform logic, "Transfer Objects" to provide and OOP representation of  
the data, and "Data Access Layer" to abstract raw database calls that 
can be tweaked for performance, but anyway...

>
> Components are reusable interface widgets essentially.  They are not 
> modules, period.  My thinking here is that components follow a basic 
> model.  The one we have now would serve the purpose.  Now, the 
> important thing is, anyone can write any component they want.  So, if 
> I like QuickForm, Jaxn like PHPObjects and Patrick likes PatForms, we 
> could all wrap those packages into different CEP components.  Or, they 
> could all suck and we wrote our own.  The point being, the component 
> isn't core, the component model is.  A healthy diverse component 
> repository would be encouraged in this model.

I think I agree, but I am starting to wonder what the hell modules are.  
I know that the original idea behind modules was similar to kernel 
modules in that if they are present then they are functional while if 
they aren't present then they aren't needed.  It was along the lines of 
"if there is a comments module available, provide comment functionality 
on the blog, if not then don't" and that you could choose which 
"comments module" you wanted to use.  That idea was back in the 
"cataBlog" days, pre CEP-0.1.  While it is a good idea, it does not 
describe the functioality of components at all.

I do think that we have been loosly referring to "pages" as modules, and 
that may not be accurate.

I also love the flexibility we offer developers.  I was thinking today 
about writing an article called "CEP c.r.u.d. tools: variations on a 
theme" just for fun.

>
> Modules can be called from within other Modules natively as they are 
> part of CEP ($module = new Module), or then can be requested through 
> any of the transport bootstraps, either way, the returned value should 
> be valid UTF-8 XML.

How is that different from components?

>
> The XSLT aspect can be left out since you can return valid XML/XHTML 
> from a module, or it can always be used, since XSLT always works on 
> valid XML.  Up the the developer.  Again, this isn't core, however 
> forcing all modules to return valid UTF-8 XML would be a core 
> requirement.

What is the advantage of making it UTF-8?  I agree that we should make 
all XML be valid (including HTML), but why UTF-8 encoding?  I also agree 
about leaving XSLT out.  That goes against the "PHP is a templating 
language" argument and seems like double parsing to me.  I am all for 
having the option, just wouldn't want to require it.

>
> The diagram is attached, lemme know what you think.  This is just a 
> brainstorm.
>
> Side Note: This diagram offers PHP4 and PHP5 suggested package notes.  
> My hope is that this, or something similar, could be achieved in both 
> branches, I don't think PHP4 is dead just yet, although PHP5 is far 
> more elegant.

I like the diagram. I ommitted it from the reply to save bandwidth.

PHP4 may not be dead, but it is "dead to me".  I do however appreciate 
your willingness to still support it in some capacity.

Just an FYI, I am dealing with some of the same issues and have blogged 
a little comparison (including a little diagram of my own at the bottom).
http://jaxn.org/blog/archives/522-Developing-Component-Based-Web-Applications.html

-Jackson