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

[Marcus W. <ma...@ph...>]

Jackson Miller wrote:

> 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. :)

Hah.

>
>>
>> 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.
>
ok.

>>
>> 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...
>
ok.  I'm not sure where this will go beyond preference.  I could go 
either way.

>>
>> 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.

Modules are public Application API.

>
> I do think that we have been loosly referring to "pages" as modules, 
> and that may not be accurate.
>
I think "Pages" are just unique identifiers, like a namespace or 
something.  It all goes back to request / response.  HTTP method calls 
and XML data is what moves in and out of the application.  Modules, to 
me, is the public API of the application.  Bootstraps just wrap the 
requests in a particular transport with a particular vernacular.  
"Pages" is a concept, which could be called anything else that served as 
a unique identifier for a registered instance of a module.

> 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.

Nice.

>
>>
>> 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 main thing I would think about components is that they aren't 
registered.  If the component model and the module model were the exact 
same (which they can be), the one thing that would differentiate the two 
is the cep_modules table in the schema.  Of course, many times you can 
logically discern when a body of code should be either a component or a 
module.  Just because they are interoperable doesn't mean that many 
components would ever be used as a registered module.  I think 
components are more like developers tools, and modules are like plug and 
play tools for the everyday user.  It may be clearer to think of these 
in this way than in a code way?

>>
>> 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.

ok.  The advantage would be that UTF-8 is the default char set for XML 
and by mandate supported by all XML parsers: 
http://www.w3.org/TR/REC-xml/#charencoding

I understand the point made however.  This is an idea I'm experimenting 
with.  I'm not all the way with it, however I'm beginning to think that 
XML/XSL is the best way to start a presentation object. 

>
>>
>> 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.

Thanks.

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

Understandable.  I think that PHP5 is still on it's way.  Like I said, 
it's more elegant and powerful in a lot of ways, however PHP 4 is still 
the one in production for the big apps of today, and in some camps a 
PHP4 implementation of CEP will be a lot less daunting of a switch than 
a jump to 5 and a new framework.  People are still trying to figure out 
PHP5.  Friendster and Flickr are still PHP4 at the moment.

>
> 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 
>

interesting read.  Look forward to seeing good things from Axson

I'm off to work on the book.

- Marcus