Re: [Components] Thoughts about components for cronjobs
On Thu, Sep 16, 2010 at 10:32 PM, Xiongjie Chen x...@ez.no wrote: Hello everyone, Today I discussed with some partner developers about one topic. We got the feeling that cronjob is not so easy to configure(especially there are many tasks), manage (monitor, control). Then I thought a little bit how to improve this, it should be great if there are some components in zeta components for this. Also I think this is good and general need for 'enterprise use'. I also found this one: http://pear.php.net/package/System_Daemon/docs but it's just a daemon, which is not enough. Ideally there should be a tool/possibility to configure task, control task, monitor task/memory use, etc. Any idea on this or there is already some existence but I didn't know? Why would PHP do a better job than Bash at this system administration job? Regards James -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rey. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] New website: zetac.org
Hello everybody, Zetac.org provides the following shortcuts: * zetac.org/base - tutorial of component Base * zetac.org/Base - tutorial of component Base * zetac.org/ezcbase - api of class ezcBase * zetac.org/ezcBase - api of class ezcBase More info on zetac.org Hope that helps ;) James -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rey. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] RE : cool web apps based on the components
On Fri, Jul 31, 2009 at 12:49 PM, Nicolas Pastorino n...@ez.no wrote: Simply having a page where they can be put on ezcomponents.org may trigger the first example. Bumping to close this question ;) Everybody can add his app on the wiki: http://ezcusers.org/Sites http://ezcusers.org/Softwares http://ezcusers.org/Softwares http://ezcusers.org/Frameworks Feel free to create teaser pages, or use it for the documentation of your software like http://ezcusers.org/madFramework Cheers James -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rei. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Goodbye eZ Components . welcome Zeta Components!
What would be the point of changing prefix? -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rei. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] setup env bash script
I slightly elaborated on http://ezcusers.org/DumbAutoload Regards -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rei. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] 2010 roadmap
On Sun, Apr 11, 2010 at 8:34 AM, Piotrek Karas p.karas.li...@mediaself.pl wrote: * - I wrote kind of independent because as far as I know eZC were to become the building blocks for eZ Publish and other solutions. However, they seem a very stable and independent project/product today. It is stable, with i guess a total active user base of ~20-25 persons. Many eZ Component users reinvent the same things: auth/profile applications, schema migration tools, production commands, form configuration stuff IMHO it would be much easier to pass the 100 active users if new users would not have to reinvent what previous users made. This would allow eZC to grow at the same rhythm as its active user base. Regards James -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rei. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] CRUD
On Fri, Mar 19, 2010 at 12:55 PM, Thomas, Maxime maxime.tho...@logica.com wrote: Hi, I would like to know if there’s a crud component which will be a “PersistentObjectMvcToolsTieIn” and that will provide some easy kind of structure to generate CRUD actions and controllers. I’ve done one by my side but I would like to know if there’s an existant component or if I can share my thoughts. I think many active users implemented it on their own. It is a great idea to make an MvcPersistentTiein component. Did you read http://ezcomponents.org/contributing/dev_process ? You can post a requirements document proposal on the mailing list, and wait for feedback while opening your current sources on github or something like that. Regards, James -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rei. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] setup env bash script
Good initiative, i'll share mine ;) I use one autoload array for all components and my classes, generated by this script: #!/bin/sh scanPath=. if [[ $1 != ]]; then scanPath=$1; fi; echo ?php; echo return array(; echo `find -L $scanPath -name *php | xargs grep ^class | sed -e s...@\([^:]*\):class \([^ ]*\).*@'\2' = '\1',\ @`; echo `find -L $scanPath -name *php | xargs grep ^abstract class | sed -e s...@\([^:]*\):abstract class \([^ ]*\).*@'\2' = '\1',\ @`; echo `find -L $scanPath -name *php | xargs grep ^interface | sed -e s...@\([^:]*\):interface \([^ ]*\).*@'\2' = '\1',\ @`; echo );; echo ?; -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rei. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] CRUD
BTW, a message to users making CRUD stuff. I highly recommend to respect uni-form standard, and to use the client-side validation plugin. http://sprawsm.com/uni-form/ http://ilija.biz/projects/uniform/ It also saves a lot of time to developers with few CSS/JS skills ;) Enjoy Regards James -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rei. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Unofficial wiki
Hello everybody, I installed a MediaWiki for eZ Components users to promote their work, and make it easier for other users to find and enjoy. It contains about all i can think of off the top of my head, feel free to add stuff, create pages, etc, etc http://www.ezcusers.org Regards, James -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rei. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] 2010 roadmap
On Mon, Feb 8, 2010 at 11:19 AM, Piotrek Karas p.karas.li...@mediaself.plwrote: I wonder what that means in terms of eZ Components as a product - will that seize to exist on its own (or in other words: outside of being part of future eZ Publish)? What do you think? eZ Components is used in other projects than eZ Publish like Arbit tracker, Jetfuel framework or WCV to name some open source ones. That said, can you define/elaborate *technically* the concept seizing to exist on its own (outside of being part of future eZ Publish)? Regards -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rei. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] MvcTools: specialized HTTP response codes
On Fri, Feb 26, 2010 at 4:38 PM, Thomas Nunninger tho...@nunninger.info wrote:
Hi,
after updating some content in my application, I want to redirect with a 303
HTTP response code. If I use ezcMvcExternalRedirect it uses a very unspecific
302 code. In HTTP 1.1 you could use 301 and 307 instead of 302.
The German wikipedia (http://de.wikipedia.org/wiki/HTTP-Statuscode) even
states not to use the 302 redirect when redirecting to other sites because of
an search engine error (URL hijacking).
Finally I think, I should not patch ezcMvcExternalRedirect but extend it with
semantic meanings like content updated, show normal view, content is
available on other location and so on.
But I even need some patch like:
--- response_writers/http.php (Revision 94)
+++ response_writers/http.php (Arbeitskopie)
@@ -73,7 +73,14 @@
// write output
foreach ( $this-headers as $header = $value )
{
- header( $header: $value );
+ if ( !is_array( $value ) )
+ {
+ header( $header: $value );
+ }
+ else
+ {
+ header( $header: {$value[0]}, true, $value[1] );
+ }
}
// do cookies
foreach ( $this-response-cookies as $cookie )
If the value of the header is an array, the second entry is the status code.
Otherwise, everything behaves like before.
The code seems to be a little bit hackish (because of the semantic in a simple
array struct). But I don't have another idea without breaking BC.
What do you think?
Wouldn't it be nice to add an $httpCode attribute to ezcMvcResponse
and use it in ezcMvcHttpResponseWriter?
Regards
--
http://jamespic.com/contact
Customer is king - Le client est roi - El cliente es rei.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] eZ Components 2009.1.2 released!
On Tue, Sep 1, 2009 at 4:41 PM, Derick Rethansd...@ez.no wrote: Hello! This bug fix release addresses a few issues in the following components: Archive, Authentication, Configuration, MvcTools, Search, SystemInformation and Template. Congratulations for this new release! Keep up the good work :) Regards, James -- http://jamespic.com/contact -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] RE : cool web apps based on the components
Hi, We use eZ Components in two of our commercial products: GestiShop and Magesti (see http://actif2i.com for more informations). Can a example business case be posted so that i get a better idea of what you expect? Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] RE : cool web apps based on the components
Hi, Do you think drafts should be posted so that we can help each other? Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] RE : cool web apps based on the components
On Fri, Jul 31, 2009 at 6:07 PM, Thomas, Maximemaxime.tho...@logica.com wrote: Maybe we can just exchange the overview. If there's a hidden feature in the ezc.org website, I guess that Derick can help by tolding us what fields are necessary. In my own opinion, I think we need the following information: * The name of the project / the client * The list of used components * The different volumes: number of visits, number of pages, things like this. * The number of days of work * The added value of our job! Another thing? The list is application-specific, it is probably pretty complete your project. I will try to offer my help if you post a draft on the mailing-list. Regards, James. PS: please avoid postponing. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Thoughs on the Identity Map
Hi, On Mon, Jun 1, 2009 at 11:02 PM, Tobias Schlittt...@ez.no wrote: On 06/02/2009 12:29 AM Benjamin Eberlei wrote: A minor detail that i didn't like so much is the code-duplication of identity map decorator and the load handler, which is difficult to eliminate due to both of them being far away in the package structure. But considering that the 3 handlers have only been created to simplify the persistent object manager they still belong together somehow. Maybe it is time to abstract'ize the loader (possible the save and delete handler too) and make the identity map decorator have one implementation also that removes code duplication. Abstract handlers have the advantage that they help in the further development of PO with new features. Could you elaborate a bit more on how this could happen? I still don't get the main point. Maybe Benjamin is partly talking about the fact that the user can't set his own handler objects to the session. IIRC this was not considered an interesting feature last time it was requested and discussed on IRC. This relates to another feature that was discussed: object-class reversal and object instantiation refactor. The big idea behind that was to encapsulate all get_class() and new calls into methods of the session, allowing meta programming of the model layer. This would also solve the requirements discussed when the Repository component was proposed, and might not require major changes in PersistentObject sources. Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Proposal: Session handling component
Hi, On Fri, May 8, 2009 at 2:26 PM, Jiayong Oujiayong...@ymc.ch wrote: So far, our requirements are: - Pluggable session storage (e.g. MySQL, Memcached) - Caching - Support for locking Can you elaborate requirements please? Why use MySQL or Memcached or locking? Is it sure there will be performance improvement compared to natively supported solutions like tmpfs? Any plans to support simple namespacing for multi-applications projects? Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Framework component research
Hi, As promised to Toby, this email concerns research I've made for the form component requirements. eZ Publish team works hard on making the kernel more modular and modules easier to do with the recent developer API, but eZ is still responsible not only for the kernel but also the components. Django made it possible to develop applications that are reusable in different projects. The demand is considerably high: there are thousands of apps hosted on google. Reusing this applications should highly reduce development and maintenance costs, although their documentation did not take this in account, making 90% of the apps not over loadable. Development and maintenance costs would decrease with eZ Components if only the Framework allowed to create reusable and overloadable applications. This is the reason why i made this research/poc. Research proven needs: - a template location that allows overloading, - a persistent definition manager that loads persistent object definitions of all applications, - a shortcut method for the mvc router to import routes more easily, - result object namespacing: to know from which app to import the views, Other needs i can think of follow. Application static stuff (css, js ...) Those should be bundlable in a convenient for httpd configuration. Dependencies between applications Pear can not only do that, but also allow making a future application package manager. Inter-component communication Factories like ezcMvcRequest+ezcDbSchema-PersistentObject instance, PersistentObjectDefinition+ezcDbSchema-ezcUserInput definition, etc, etc ... Two solutions: either make the user maintain all definitions and load them all in an abstract factory class; or make an intermediary form - which i still highly recommend because it could also be used to generate HTML (be details of an object, an object list table or even a form and userinput definition). Overloadable applications Basically that's mostly solved by MvcTools, are left-over: static stuff, definitions (po, ui, etc, etc ...). Sources: http://github.com/jpic/ezc-framework-apps/tree http://blog.chocolatpistache.com/blog/tag/django/ Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] CAPTCHA Component
On Wed, Apr 8, 2009 at 10:54 AM, Christoph Friedrich se...@dragons-server.de wrote: Hi there, has anybody written a CAPTCHA Component which can easily handle CAPTCHAs? Or is the there only the ezcAuthenticationTokenFilter? Hi, An array of question-answers can be used for text humanoid verification, it works very well and you are free to consider this option, as well as the reCAPTCHA API. You should consider options depending on your target audience and consideration of accessibility standards. Components might consider supporting captchas for UserInput. Captcha is not a feature likely to have its place in the Authentication component. Maybe you were talking about CSRF security liability? Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] snippets.ez.no application: requirements
Hello everybody, I'm glad to present the snippets application requirements document. It is structured differently than a component requirements document because it is an application requirements document. As usual: feel free to give any sort of feedback. Regards, James. snippets.ez.no.requirements.rst Description: Binary data -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Validator/Repository component proposal requirements rewrite
Hello everybody, Added requirement: - Provide data structure definition merge algorythms implementations. Added question: - Shouldn't the validator classes be part of Base? Any feedback will be appreciated! eZ Component: Validator, Requirements ~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ Target and scope The scope of this document is to describe the requirements for a component providing classes to implement a structured data validator to develop domain-driven applications. This document does not describe the design of the named component, but only summarizes the requirements for it to be discussed on the developer mailing list. Where suitable, design related topics will be touched, but a dedicated design document is available, defining APIs, classes and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. Introduction Description --- The goal of the Validator component is to give users a basis for implementing structured data for applications written in PHP 5. eveloping a model driven `Software Framework`_ requires coding a re-usable API, loosely coupled with the application specific data structures itself. This means, in MVC terms, that changing the data structure should not cause any change of the Controller, Model or View layer - unless any has behaviours overloaded for application specific needs - making it much easier to test any M, V, C layers. Current implementation -- A hack for javascript hack for Django admin app was releasing under WTFPL license: http://www.djangosnippets.org/snippets/1358/ It is useful with model-inheritance or metaclasses. This component should not require metaclasses or validator-wrapper inheritance, but would make it possible. Component integration = eZ Components already provides libraries that are useful for implementing a `Software Framework`_. One basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through so-called tie-in components. Therefore the mechanisms realized in an `Software Framework`_ component should be that far abstracted, that other components can be tied in and provide only very basic implementations on its own. This also allows users to implement their own mechanisms. The following components have been identified as possible tie-ins: - PersistentObject_ (models) - DatabaseSchema_ (models) - Workflow_ (crud controller) - MvcTools_ (user interface) - UserInput_ (controllers) .. _PersistentObject: http://ezcomponents.org/docs/tutorials/PersistentObject .. _DatabaseSchema: http://ezcomponents.org/docs/tutorials/DatabaseSchema .. _MvcTools: http://ezcomponents.org/docs/tutorials/MvcTools .. _UserInput: http://ezcomponents.org/docs/tutorials/UserInput .. _Workflow: http://ezcomponents.org/docs/tutorials/Workflow For each of these components a tie-in component could considered to be implemented at a later stage. This should be kept in mind when designing the classes/interfaces for the Validator component component. A repository implementation could be provided, coupling phpillow_, a CouchDB DBAL. Design requirements === - A data structure definition coded with the Validator component should not require loading any library other than the Validator compnonent and user defined classes (no UI_, ORM_, DBAL_, MVC_ implementations ...). - Structured data should contain their own definitions. - Support for two-way development: reverse engineer existing storage data structures. - Never require data structure change propagation: let the user concentrate on his application specific `Software Framework`_. - Support for client (PHP) side state full constraints (validator mutation). - Data structure validation, diff. - Support for data structure validators encapsulation: validator wrapping. - Support for validators agregating and inheritance. - Support for data structures creation on-the-fly. - Support for multiple persistency design: - RDBMS_ - eZPublish_ - CouchDB_ - Provide a fixture generator. - Provide data structure definition merge algorythms implementations. Special Considerations == Shouldn't the validation classes be part of Base? We should keep testing capabilities for the extensions to this component and the applications build upon it in mind during the design and implementation phase. We cannot provide the testing environment itself: - Does not fit into the component - Our test component is not an official component and can only be used to test eZ Components themselves. Clarification of terms == .. _Repository: http://martinfowler.com/eaaCatalog/repository.html .. _Software Framemork: http://en.wikipedia.org/wiki/Software_Framework .. _MVC: http://en.wikipedia.org/wiki/Model-view-controller
Re: [Components] Validator/Repository component proposal requirements rewrite
Hello everybody, Added requirement: - Provide a fixture generator. Any feedback will be appreciated! eZ Component: Validator, Requirements ~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ Target and scope The scope of this document is to describe the requirements for a component providing classes to implement a structured data validator to develop domain-driven applications. This document does not describe the design of the named component, but only summarizes the requirements for it to be discussed on the developer mailing list. Where suitable, design related topics will be touched, but a dedicated design document is available, defining APIs, classes and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. Introduction Description --- The goal of the Validator component is to give users a basis for implementing structured data for applications written in PHP 5. eveloping a model driven `Software Framework`_ requires coding a re-usable API, loosely coupled with the application specific data structures itself. This means, in MVC terms, that changing the data structure should not cause any change of the Controller, Model or View layer - unless any has behaviours overloaded for application specific needs - making it much easier to test any M, V, C layers. Current implementation -- A hack for javascript hack for Django admin app was releasing under WTFPL license: http://www.djangosnippets.org/snippets/1358/ It is useful with model-inheritance or metaclasses. This component should not require metaclasses or validator-wrapper inheritance, but would make it possible. Component integration = eZ Components already provides libraries that are useful for implementing a `Software Framework`_. One basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through so-called tie-in components. Therefore the mechanisms realized in an `Software Framework`_ component should be that far abstracted, that other components can be tied in and provide only very basic implementations on its own. This also allows users to implement their own mechanisms. The following components have been identified as possible tie-ins: - PersistentObject_ (models) - DatabaseSchema_ (models) - Workflow_ (crud controller) - MvcTools_ (user interface) - UserInput_ (controllers) .. _PersistentObject: http://ezcomponents.org/docs/tutorials/PersistentObject .. _DatabaseSchema: http://ezcomponents.org/docs/tutorials/DatabaseSchema .. _MvcTools: http://ezcomponents.org/docs/tutorials/MvcTools .. _UserInput: http://ezcomponents.org/docs/tutorials/UserInput .. _Workflow: http://ezcomponents.org/docs/tutorials/Workflow For each of these components a tie-in component could considered to be implemented at a later stage. This should be kept in mind when designing the classes/interfaces for the Validator component component. A repository implementation could be provided, coupling phpillow_, a CouchDB DBAL. Design requirements === - A data structure definition coded with the Validator component should not require loading any library other than the Validator compnonent and user defined classes (no UI_, ORM_, DBAL_, MVC_ implementations ...). - Structured data should contain their own definitions. - Support for two-way development: reverse engineer existing storage data structures. - Never require data structure change propagation: let the user concentrate on his application specific `Software Framework`_. - Support for client (PHP) side state full constraints (validator mutation). - Data structure validation, diff. - Support for data structure validators encapsulation: validator wrapping. - Support for validators agregating and inheritance. - Support for data structures creation on-the-fly. - Support for multiple storage models: - Provide a fixture generator. - RDBMS_ - eZPublish_ - CouchDB_ Special Considerations == We should keep testing capabilities for the extensions to this component and the applications build upon it in mind during the design and implementation phase. We cannot provide the testing environment itself: - Does not fit into the component - Our test component is not an official component and can only be used to test eZ Components themselves. Clarification of terms == .. _Repository: http://martinfowler.com/eaaCatalog/repository.html .. _Software Framemork: http://en.wikipedia.org/wiki/Software_Framework .. _MVC: http://en.wikipedia.org/wiki/Model-view-controller .. _UI: http://en.wikipedia.org/wiki/UI .. _ORM: http://en.wikipedia.org/wiki/Object-relational_mapping .. _DBAL: http://en.wikipedia.org/wiki/DBAL .. _Naked Objects: http://en.wikipedia.org/wiki/Naked_objects .. _CRUD: http
[Components] Proposal: Validator
Hello everybody, Thanks beberlei, this rewritten version of the component proposal is more straight to the point imho. Basically, this component is about defining data structures with constraints, not coupling with any ORM/DBAL/UI component of any sort, and where the objects structure is avalaible along with the object (self-descriptive). Looking forward to read feedback! Regards, James. -- A: Yes, but then I don't understand the question. Q: Can I post your message at the bottom of mine? --- framework_proposal.txt 2009-02-05 12:09:52.0 +0100 +++ validator_proposal.txt 2009-02-05 12:08:46.0 +0100 @@ -1,5 +1,5 @@ -eZ Component: FrameworkTools, Requirements -~ +eZ Component: Validator, Requirements +~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ @@ -8,14 +8,12 @@ The scope of this document is to describe the requirements for a component -providing classes to implement a SoftwareFramework_ architecture to develop -data-driven applications. -This document does not describe the design of the named component, but only -summarizes the requirements for it to be discussed on the developer mailing -list. Where suitable, design related topics will be touched, but a -dedicated -design document is available, defining APIs, classes and the architectural -structure of the component. +providing classes to implement a structured data validator to develop +data-driven applications. This document does not describe the design of the +named component, but only summarizes the requirements for it to be discussed +on the developer mailing list. Where suitable, design related topics will be +touched, but a dedicated design document is available, defining APIs, classes +and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. @@ -23,97 +21,95 @@ Introduction -The goal of FrameworkTols component is to give users a basis for such -architectures for web applications written in PHP 5. +The goal of the Validator component is to give users a basis for implementing +structured data for applications written in PHP 5. -The compononent shall not provide a fully featured implementation of a -SoftwareFramework_, but should help users to easily create their own, -custom implementations; although Tiein will be implemented to make features -easely usable. - -Developing a SoftwareFramework_ highly involves creating code that is -re-usable independently of the application specific data structures. - -This means, in MVC terms, that changing the data structure should not -cause any change of the Controller, Model or View layer - unless any -has behaviours overloaded for application specific needs. +The component shall not provide a fully featured implementation of a +Repository_, but should help users to easily create their own, custom +implementations; although Tiein will be implemented to make features easily +usable. + +Developing a model driven `Software Framework`_ highly involves creating code +that is re-usable independently of the application specific data structures. + +This means, in MVC terms, that changing the data structure should not cause +any change of the Controller, Model or View layer - unless any has behaviours +overloaded for application specific needs. Data driven applications -Design patterns like `Naked Objects`_ allow to build a data driven -application with high overhead but low cost. +Design patterns like `Naked Objects`_ allow to build a data driven application +with high overhead but low cost. -There is currently no PHP implementations of `Naked Objects`_ design -pattern. +There is currently no PHP implementations of `Naked Objects`_ design pattern. -The PHP object model does not allow to implement this design pattern like -Java +The PHP object model does not allow to implement this design pattern like Java but still allows it to implement it properly, without coupling the data -structure definitions with application specific code of UI, ORM/DBAL ... -(or even: Models, Views or Controller layers). +structure definitions with application specific code of UI, ORM/DBAL ... (or +even: Models, Views or Controller layers). Flexible data structures -eZ Publish currently solves this problematic, but there is no loosly coupled +eZ Publish currently solves this problematic, but there is no loosely coupled component that allows it. The strength of DatabaseSchema_ and PersistentObject_ components is demonstrated when implementing a data structure for a agilely designed application. -The experience shows that in most cases: +The experience shows that in some cases: - a quote must be done before being supplied with detailed data structures. -- it is very hard for the client to allocate budget
Re: [Components] Proposal: FrameworkTools
After Gaetano's relevant input (off-mailing list), this is the new version. Thanks again Gaetano, not only for the revelance of your input but also for your support on a Sunday! Updates: - moved the eZ Publish db schema style from Special Considerations to Requirements list, - added some Requirements, - factorized and re-structured Introduction. Read below: eZ Component: FrameworkTools, Requirements ~~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ Target and scope The scope of this document is to describe the requirements for a component providing classes to implement a SoftwareFramework_ architecture to develop data-driven applications. This document does not describe the design of the named component, but only summarizes the requirements for it to be discussed on the developer mailing list. Where suitable, design related topics will be touched, but a dedicated design document is available, defining APIs, classes and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. Introduction The goal of FrameworkTols component is to give users a basis for such architectures for web applications written in PHP 5. The compononent shall not provide a fully featured implementation of a SoftwareFramework_, but should help users to easily create their own, custom implementations; although Tiein will be implemented to make features easely usable. Developing a SoftwareFramework_ highly involves creating code that is re-usable independently of the application specific data structures. This means, in MVC terms, that changing the data structure should not cause any change of the Controller, Model or View layer - unless any has behaviours overloaded for application specific needs. Data driven applications Design patterns like `Naked Objects`_ allow to build a data driven application with high overhead but low cost. There is currently no PHP implementations of `Naked Objects`_ design pattern. The PHP object model does not allow to implement this design pattern like Java but still allows it to implement it properly, without coupling the data structure definitions with application specific code of UI, ORM/DBAL ... (or even: Models, Views or Controller layers). Flexible data structures eZ Publish currently solves this problematic, but there is no loosly coupled component that allows it. The strength of DatabaseSchema_ and PersistentObject_ components is demonstrated when implementing a data structure for a agilely designed application. The experience shows that in most cases: - a quote must be done before being supplied with detailled data structures. - it is very hard for the client to allocate budget for the software engineer to come on site and detail the data structure. - it is very hard to have a detailled data structure even when the quote was accepted anyway... Data structures with eZ Components -- eZ Components does not yet provide a library to design the data structure once and only once. Developping generic frameworks providing a generic CRUD_ controller require loading both the DatabaseSchema_ and PersistentObject_ components: - DatabaseSchema_ provides complete informations about fields, - PersistentObject_ provides complete informations about objects and relations. Three solutions are possible: - Embed the field informations in PersistentObject_, deriving from its original requirements, making it able to replace DatabaseSchema_ with high overhead. - Embed the relations informations in DatabaseSchema_, but then PersistentObject_ would still be needed or else arrays and arrays of arrays would have to be dealt with. - Use a third component to define the complete data structure: fields and relations at once. Provide tieins to generate definitions not only for DatabaseSchema_ and PersistentObject_, but also other components like UserInput_ or Workflow_. Component integration = eZ Components already provide some components that are useful when implementing a SoftwareFramework_. However, one basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through so-called tie-in components. Therefore the mechanisms realized in an SoftwareFramework component should be that far abstracted, that other components can be tied in and provide only very basic implementations on its own. This also allows users to implement their own mechanisms. The following components have been identified as possible tie-ins: - PersistentObject_ (models) - DatabaseSchema_ (models) - Workflow_ (crud controller) - MvcTools_ (user interface) - UserInput_ (controllers) .. _PersistentObject: http://ezcomponents.org/docs/tutorials/PersistentObject .. _DatabaseSchema: http
Re: [Components] Proposal: FrameworkTools
Don't we also need some constraint definition feature? Thinking of this after adding the Nth hundred line of custom Javascript UI mutation. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Proposal: FrameworkTools
On Sun, Dec 21, 2008 at 5:46 PM, James PIC james...@gmail.com wrote: Don't we also need some constraint definition feature? Thinking of this after adding the Nth hundred line of custom Javascript UI mutation. Added in Design Requirements, thanks james! Also: spelling check. eZ Component: FrameworkTools, Requirements ~~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ Target and scope The scope of this document is to describe the requirements for a component providing classes to implement a SoftwareFramework_ architecture to develop data-driven applications. This document does not describe the design of the named component, but only summarizes the requirements for it to be discussed on the developer mailing list. Where suitable, design related topics will be touched, but a dedicated design document is available, defining APIs, classes and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. Introduction The goal of FrameworkTols component is to give users a basis for such architectures for web applications written in PHP 5. The compononent shall not provide a fully featured implementation of a SoftwareFramework_, but should help users to easily create their own, custom implementations; although Tiein will be implemented to make features easely usable. Developing a SoftwareFramework_ highly involves creating code that is re-usable independently of the application specific data structures. This means, in MVC terms, that changing the data structure should not cause any change of the Controller, Model or View layer - unless any has behaviours overloaded for application specific needs. Data driven applications Design patterns like `Naked Objects`_ allow to build a data driven application with high overhead but low cost. There is currently no PHP implementations of `Naked Objects`_ design pattern. The PHP object model does not allow to implement this design pattern like Java but still allows it to implement it properly, without coupling the data structure definitions with application specific code of UI, ORM/DBAL ... (or even: Models, Views or Controller layers). Flexible data structures eZ Publish currently solves this problematic, but there is no loosly coupled component that allows it. The strength of DatabaseSchema_ and PersistentObject_ components is demonstrated when implementing a data structure for a agilely designed application. The experience shows that in most cases: - a quote must be done before being supplied with detailed data structures. - it is very hard for the client to allocate budget for the software engineer to come on site and detail the data structure. - it is very hard to have a detailed data structure even when the quote was accepted anyway... Data structures with eZ Components -- eZ Components does not yet provide a library to design the data structure once and only once. Developping generic frameworks providing a generic CRUD_ controller require loading both the DatabaseSchema_ and PersistentObject_ components: - DatabaseSchema_ provides complete information about fields, - PersistentObject_ provides complete information about objects and relations. Three solutions are possible: - Embed the field information in PersistentObject_, deriving from its original requirements, making it able to replace DatabaseSchema_ with high overhead. - Embed the relations information in DatabaseSchema_, but then PersistentObject_ would still be needed or else arrays and arrays of arrays would have to be dealt with. - Use a third component to define the complete data structure: fields and relations at once. Provide tieins to generate definitions not only for DatabaseSchema_ and PersistentObject_, but also other components like UserInput_ or Workflow_. Even if any of the two first solutions where selected, keep in mind that UserInput_ definitions should also be parsed for constraints. Component integration = eZ Components already provide some components that are useful when implementing a SoftwareFramework_. However, one basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through so-called tie-in components. Therefore the mechanisms realized in an SoftwareFramework component should be that far abstracted, that other components can be tied in and provide only very basic implementations on its own. This also allows users to implement their own mechanisms. The following components have been identified as possible tie-ins: - PersistentObject_ (models) - DatabaseSchema_ (models) - Workflow_ (crud controller) - MvcTools_ (user interface) - UserInput_ (controllers) .. _PersistentObject: http://ezcomponents.org/docs/tutorials
[Components] Proposal: FrameworkTools
Hello everybody, Again I've done my best to produce a relevant and comprehensive requirements document for a component idea: FrameworkTools. Enjoy your reading! Please feel free to submit feedback! Regards, James. eZ Component: FrameworkTools, Requirements ~~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ Target and scope The scope of this document is to describe the requirements for a component providing classes to implement a SoftwareFramework_ architecture to develop data-driven applications. This document does not describe the design of the named component, but only summarizes the requirements for it to be discussed on the developer mailing list. Where suitable, design related topics will be touched, but a dedicated design document is available, defining APIs, classes and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. Introduction The goal of FrameworkTols component is to give users a basis for such architectures for web applications written in PHP 5. The compononent shall not provide a fully featured implementation of a SoftwareFramework_, but should help users to easily create their own, custom implementations. There are two ways to develop a SoftwareFramework_. Way 0: Develop and factorize Develop an application, factorize into re-usable libraries (Django). In this case, power users can be rapidely confronted to limitations such as lack of factorization, and the need to either: - do the decoupling himself and patch the framework, maintain his branch until the patches are accepted upstream, if ever. - re-invent what is already implemented in a contrib application. The need for BC break is also encountered when updating the framework with this kind of process. FrameworkTools should make it possible for the user to maintain a framework without causing any BC breaks. Way 1: Study needs and implement A correct study of the needs allow to implement the SoftwareFramework_ with proper object-oriented design in the first place. There should not be any factorisation left to do, BC breaks are then optionnal. The need Data driven applications Java is still in the hype for most projects that are valuable to software developers, design patterns like `Naked Objects`_ allow to build a data driven application with high overhead but low cost. There is currently no PHP implementations of `Naked Objects`_ design pattern. Flexible data structures eZ Publish currently solves this problematic, but there is no loosly coupled component that allows it. The strength of DatabaseSchema_ and PersistentObject_ components is demonstrated when implementing a data structure for a agilely designed application. The experience shows that in most cases: - a quote must be done before being supplied with detailled data structures - it is very hard for the client to allocate budget for the software engineer to come on site and detail the data structure - it is very hard to have a detailled data structure anyway! eZ Components does not yet provide a library to design the data structure once and only once. Developping generic frameworks providing a generic CRUD_ controller require loading both the DatabaseSchema_ and PersistentObject_ components: - DatabaseSchema_ provides complete informations about fields, - PersistentObject_ provides complete informations about objects and relations. Three solutions are possible: - Embed the fields informations in PersistentObject_, deriving from its original requirements, making it able to replace DatabaseSchema_ with high overhead. - Embed the relations informations in DatabaseSchema_, but then PersistentObject_ would still be needed or else arrays and arrays of arrays would have to be dealt with. - Use a third component to define the complete data structure: fields and relations at once. Provide tieins to generate definitions not only for DatabaseSchema_ and PersistentObject_, but also other components like UserInput_ or Workflow_. Component integration = eZ Components already provide some components that are useful when implementing a SoftwareFramework_. However, one basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through so-called tie-in components. Therefore the mechanisms realized in an SoftwareFramework component should be that far abstracted, that other components can be tied in and provide only very basic implementations on its own. This also allows users to implement their own mechanisms. The following components have been identified as possible tie-ins: - PersistentObject_ (models) - DatabaseSchema_ (models) - Workflow_ (crud controller) - MvcTools_ (user
Re: [Components] Proposal: FrameworkTools
Fixed a typo. eZ Component: FrameworkTools, Requirements ~~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ Target and scope The scope of this document is to describe the requirements for a component providing classes to implement a SoftwareFramework_ architecture to develop data-driven applications. This document does not describe the design of the named component, but only summarizes the requirements for it to be discussed on the developer mailing list. Where suitable, design related topics will be touched, but a dedicated design document is available, defining APIs, classes and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. Introduction The goal of FrameworkTols component is to give users a basis for such architectures for web applications written in PHP 5. The compononent shall not provide a fully featured implementation of a SoftwareFramework_, but should help users to easily create their own, custom implementations. There are two ways to develop a SoftwareFramework_. Way 0: Develop and factorize Develop an application, factorize into re-usable libraries (Django). In this case, power users can be rapidely confronted to limitations such as lack of factorization, and the need to either: - do the decoupling himself and patch the framework, maintain his branch until the patches are accepted upstream, if ever. - re-invent what is already implemented in a contrib application. The need for BC break is also encountered when updating the framework with this kind of process. FrameworkTools should make it possible for the user to maintain a framework without causing any BC breaks. Way 1: Study needs and implement A correct study of the needs allow to implement the SoftwareFramework_ with proper object-oriented design in the first place. There should not be any factorisation left to do, BC breaks are then optionnal. The need Data driven applications Java is still in the hype for most projects that are valuable to software developers, design patterns like `Naked Objects`_ allow to build a data driven application with high overhead but low cost. There is currently no PHP implementations of `Naked Objects`_ design pattern. Flexible data structures eZ Publish currently solves this problematic, but there is no loosly coupled component that allows it. The strength of DatabaseSchema_ and PersistentObject_ components is demonstrated when implementing a data structure for a agilely designed application. The experience shows that in most cases: - a quote must be done before being supplied with detailled data structures - it is very hard for the client to allocate budget for the software engineer to come on site and detail the data structure - it is very hard to have a detailled data structure anyway! eZ Components does not yet provide a library to design the data structure once and only once. Developping generic frameworks providing a generic CRUD_ controller require loading both the DatabaseSchema_ and PersistentObject_ components: - DatabaseSchema_ provides complete informations about fields, - PersistentObject_ provides complete informations about objects and relations. Three solutions are possible: - Embed the fields informations in PersistentObject_, deriving from its original requirements, making it able to replace DatabaseSchema_ with high overhead. - Embed the relations informations in DatabaseSchema_, but then PersistentObject_ would still be needed or else arrays and arrays of arrays would have to be dealt with. - Use a third component to define the complete data structure: fields and relations at once. Provide tieins to generate definitions not only for DatabaseSchema_ and PersistentObject_, but also other components like UserInput_ or Workflow_. Component integration = eZ Components already provide some components that are useful when implementing a SoftwareFramework_. However, one basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through so-called tie-in components. Therefore the mechanisms realized in an SoftwareFramework component should be that far abstracted, that other components can be tied in and provide only very basic implementations on its own. This also allows users to implement their own mechanisms. The following components have been identified as possible tie-ins: - PersistentObject_ (models) - DatabaseSchema_ (models) - Workflow_ (crud controller) - MvcTools_ (user interface) - UserInput_ (controllers) .. _PersistentObject: http://ezcomponents.org/docs/tutorials/PersistentObject .. _DatabaseSchema: http://ezcomponents.org/docs/tutorials/DatabaseSchema .. _MvcTools
Re: [Components] Proposal: FrameworkTools
After Gaetano's relevant input, i removed the part about Java which turned out to be off-topic and added two design requirements and spelling fix. Not committing in experimental repo until the component is accepted or i am explicitly granted the permission to do so. Thanks again Gaetano! I appreciated the reply a Saturday ;) Regards, James. eZ Component: FrameworkTools, Requirements ~~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ Target and scope The scope of this document is to describe the requirements for a component providing classes to implement a SoftwareFramework_ architecture to develop data-driven applications. This document does not describe the design of the named component, but only summarizes the requirements for it to be discussed on the developer mailing list. Where suitable, design related topics will be touched, but a dedicated design document is available, defining APIs, classes and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. Introduction The goal of FrameworkTols component is to give users a basis for such architectures for web applications written in PHP 5. The compononent shall not provide a fully featured implementation of a SoftwareFramework_, but should help users to easily create their own, custom implementations; although Tiein will be implemented to make features easily usable. There are two ways to develop a SoftwareFramework_. Way 0: Develop and factorize Develop an application, factorize into re-usable libraries (Django). In this case, power users can be rapidly confronted to limitations such as lack of factorization, and the need to either: - do the decoupling himself and patch the framework, maintain his branch until the patches are accepted upstream, if ever. - re-invent what is already implemented in a contrib application. The need for BC break is also encountered when updating the framework with this kind of process. FrameworkTools should make it possible for the user to maintain a framework without causing any BC breaks. Way 1: Study needs and implement A correct study of the needs allow to implement the SoftwareFramework_ with proper object-oriented design in the first place. There should not be any factorisation left to do, BC breaks are then optional. The need Data driven applications Design patterns like `Naked Objects`_ allow to build a data driven application with high overhead but low cost. There is currently no PHP implementations of `Naked Objects`_ design pattern. The PHP object model does not allow to implement this design pattern like Java but only allows it to implement it properly, without coupling UI, ORM/DBAL ... Flexible data structures eZ Publish currently solves this problematic, but there is no loosely coupled component that allows it. The strength of DatabaseSchema_ and PersistentObject_ components is demonstrated when implementing a data structure for a agilely designed application. The experience shows that in most cases: - a quote must be done before being supplied with detailed data structures - it is very hard for the client to allocate budget for the software engineer to come on site and detail the data structure - it is very hard to have a detailed data structure anyway! eZ Components does not yet provide a library to design the data structure once and only once. Developping generic frameworks providing a generic CRUD_ controller require loading both the DatabaseSchema_ and PersistentObject_ components: - DatabaseSchema_ provides complete in formations about fields, - PersistentObject_ provides complete in formations about objects and relations. Three solutions are possible: - Embed the fields in formations in PersistentObject_, deriving from its original requirements, making it able to replace DatabaseSchema_ with high overhead. - Embed the relations in formations in DatabaseSchema_, but then PersistentObject_ would still be needed or else arrays and arrays of arrays would have to be dealt with. - Use a third component to define the complete data structure: fields and relations at once. Provide tieins to generate definitions not only for DatabaseSchema_ and PersistentObject_, but also other components like UserInput_ or Workflow_. Component integration = eZ Components already provide some components that are useful when implementing a SoftwareFramework_. However, one basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through so-called tie-in components. Therefore the mechanisms realized in an SoftwareFramework component should be that far abstracted, that other components can be tied in and provide only
[Components] How to bind a UserInput field to a PersistentObject field?
Hello everybody, I'm currently working on the design of a software that will use eZ Components. Question: how to bind a UserInput field to a PersistentObject field? How to test that binding? Several solutions i can think of: 0) Duplicate field specifications in UserInput. 1) Read the field definition from the PersistentObject definition and create the UserInput field. 2) Decouple the field specification from PersistentObject into another object, and generate the PersistentObject *and* UserInput field from that. Pros and cons of each solution that i could think of. Solution 0: + fastest design to develop the first version of the software, - hardest to maintain. test: duplicate tests or make a high-level test with selenium. Solution 1: + viable for model-driven development, - requires to read the field specifications from the the database schema as well (null? lenght?) test: make a fixture of the PersistentObject, assert that the generated UserInput field matches expectations. Solution 2: + re-usability of the field for any component: makes the software cheaper to maintain, + viable for model-driven development, + useful to generate the DatabaseSchema as well, - requires the description of a standart to use for the whole application or will cost to maintain. test: make a fixture of the middle object that has the fields specifications, assert the generated DabatabaseSchemaField, PersistentObjectField and UserInput field. Thanks in advance for your input! Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PersistentObject 1.5 design issues (summary and ideas)
Hi! Tobias Schlitt wrot Refetching objects == Problem --- It might be desirable to re-fetch a set of objects during a request. A global switch in the ezcPersistentIdentityMap instance will allow this to happen. If this switch is turned on, ezcPersistentIdentitySession should fetch the values of the affected objects from the database again and cache them. Solution The $refetch option will be moved from ezcPersistentIdentityMap to ezcPersistentIdentitySession. If it is turned on, the session will not ask the identity map for an identity, but directly issue the query. The results of this query will be replaced into the identity map, using a new replaceObject() method. This method will check, if an identity of the object already exists. Is this the case, it will replace the values in the existing identity with the values of the submitted object and return the existing identity. If no identity exists, the submitted identity will be recorded and returned. The session will always replace the fetched object with the one returned from replaceObject(). Is it ok to couple the persistent session with the identity map? I don't mind because i will use it anyway. I agree that it should not be optionnal. Will replaceObject() be used when updating an object? I think it should. Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Hi Tobias!
Tobias Schlitt wrote:
On 07/04/2008 01:25 PM James Pic wrote:
Tobias Schlitt wrote:
On 07/02/2008 02:11 PM James PIC wrote:
On Wed, Jul 2, 2008 at 9:19 AM, Tobias Schlitt [EMAIL PROTECTED] wrote:
On 07/01/2008 05:53 PM James Pic wrote:
If it was for me, we would provide an extended identity map class in a
Cache tiein that maintains a request local identity map (as it does
now).
Would that really be efficient to fetch a cached state from a file
containing
500 thousands of states?
Each identity will be a single file::
$id = $class__$id;
$cache-store( $id, $persistentObject );
Can't we do this in a transparent manner?
If this was done in a session child or decorator, it could cache reverse
relations as well.
Also, i wanted to emit a signal connected to a slot that would make
statistiques
with persistent session queries, in the context of an application audit.
That sounds like an interessting idea. However, I think sending signals
in multiple places could be quite a performance issue within the
persistent session. How would you like to have it implemented?
It would cause some performance loss indeed.
This would just be used in the context of application audits, which are
processes with a short lifetime (for example, a week or two).
I think writing another decorator which emits signals on each action
sounds like a plan. However, not for 2008.2, although someone comes up
with a contribution for this tiein.
Sure, but don't we want to keep this in mind while designing?
What do we need to keep in mind here? Another decorator just wraps
around the normal session or the identity session::
class ezcPersisentSignalSession { // ... }
$sesion = new ezcPersistentSession( // ... );
$identityMap = new ezcPersistentIdentityMap( // ... );
$identitySession = new ezcPersistentIdentitySession(
$session,
$identityMap
);
$signalSession = new ezcPersistentSignalSession( $identitySession );
// or
// $signalSession = new ezcPersistentSignalSession( $session );
Anything I missed?
Actually, it's my fault again! i missed that factorization should be
though of at a later stage, when the session will have enough optionnal
features.
I also discussed the idea of making a PersistentObjectCacheTiein with
some people at the conference. Looks like there is need for it.
However,
in the current design this could be realized by offering a different
implementation of the ezcPersistentIdentityMap class, which handles the
actual mapping. (Note, this is not the ezcPersistentSession decorating
class, but the storage used by it.)
Ok, i understand that it would make sense to use Cache crud handlers,
but a
decorator for signal-slot.
I don't get the point here, could you enlighten me, please?
If identities were cached individually, we could have
load/delete/read/create
handlers that would query the Cache component, and not tie the session's
identity map with the cache.
Why won't you implement it simply as e.g. ezcPersistentCacheIdentityMap
extends ezcPersistentIdentityMap. Should be easy to do. What's wrong
with this?
As far as i'm concerned, i want to use the features of the file-system to
optimize the caching. That means that i don't want to fetch all cached
states
at each request.
You don't. The identity session will request an object from the identity
map first and the ask the database::
Will the session check on my file system if file /cache/model/someClass/23.php
exists, and use the state returned to make the object::
?php
class ezcPersistentCacheSession extends ezcPersistentSession // hack for
// ezcPersistentSessionInstance::set()
{
public function load( $class, $id )
{
$this-cache-loadIfExists( $class, $id )
}
}
BTW, does it really correspond to the PHP object model to extend the decorated
class?
Should ezcPersistentCacheSession decorate an instance of its parent, only
because of ezcPersistentSessionInstance?
Maybe allowing the user to set custom/supplied load/delete/update/save handlers
into ezcPersistentSession would:
- fix ezcPersistentSessionInstance problem,
- allow to make custom handlers,
- allow to use supplied handlers like identityMap, cache ...
Of course, it is still possible to make an ezcPersistentSession decorator that
extends ezcPersistentSession to workaround ezcPersistentSessionInstance, and
that would allow setting different handlers. But then we *have* to use
decorators to use supplied processes that could be encapsulated in different
handlers the way the DB handlers are.
In my idea of a caching identity map, the identity session will work as
follows:
Loading
---
1. Is someClass with ID 23 in memory? - Don't fetch anything, just
return the instance.
2. Is someClass with ID 23 in the cache? - Fetch it from there and
register the instance in memory.
3. Fetch someClass with ID 23 from
Re: [Components] [PersistentObject] Design: Identity map and relation pre-fetching support
Hi Tobias!
Tobias Schlitt wrote:
On 07/02/2008 02:11 PM James PIC wrote:
On Wed, Jul 2, 2008 at 9:19 AM, Tobias Schlitt [EMAIL PROTECTED] wrote:
On 07/01/2008 05:53 PM James Pic wrote:
Tobias Schlitt wrote:
On 06/27/2008 11:44 AM James Pic wrote:
The Identity Map support should be optional to not break BC and keep
flexibility. Therefore, a new class named
ezcPersistentIdentityMapSession is
implemented. This extends the current implementation
ezcPersistentSession to
make instanceof checks still work. All of the methods will be
overwritten and
new handler classes, extending the existing ones will be implemented
to reflect
the actual additions. The methods that are not supported by the new
class will
be declared private and throw an exception is used externally.
Are we sure that we don't want the persistent object session to allow
setting a handler chain?
This could allow extending PersistentObject, and creating new handlers,
not only
for the identity map, but for example with tie-ins of other components
than Database, like Cache or SignalSlot.
I don't really get your idea of a handler chain. Could you elaborate a
bit more on this?
It would be a list of handlers with priorities, but that's not a good
idea.
I wanted to cache persistent objects, which can be particularely
interresting when pre-fetch support.
This should be easy to implement by replacing the identity map itself in
the ezcPersistentIdentitySession. I also thought about caching while
designing it. Do you see any problem here?
Do we want to cache the complete identity map(s) in order to load it in the
persistent session for another server-request;
or do we want to cache individual identities?
This is your choice actually. :) I think we won't provide a tiein with
Cache for the upcoming release, since there is too much other stuff to
do. However, you can still build that on your own for custom use.
I though that we had to keep in mind the future caching features while
designing?
If it was for me, we would provide an extended identity map class in a
Cache tiein that maintains a request local identity map (as it does
now).
Would that really be efficient to fetch a cached state from a file containing
500 thousands of states?
Also, i wanted to emit a signal connected to a slot that would make
statistiques
with persistent session queries, in the context of an application audit.
That sounds like an interessting idea. However, I think sending signals
in multiple places could be quite a performance issue within the
persistent session. How would you like to have it implemented?
It would cause some performance loss indeed.
This would just be used in the context of application audits, which are
processes with a short lifetime (for example, a week or two).
I think writing another decorator which emits signals on each action
sounds like a plan. However, not for 2008.2, although someone comes up
with a contribution for this tiein.
Sure, but don't we want to keep this in mind while designing?
I also discussed the idea of making a PersistentObjectCacheTiein with
some people at the conference. Looks like there is need for it. However,
in the current design this could be realized by offering a different
implementation of the ezcPersistentIdentityMap class, which handles the
actual mapping. (Note, this is not the ezcPersistentSession decorating
class, but the storage used by it.)
Ok, i understand that it would make sense to use Cache crud handlers,
but a
decorator for signal-slot.
I don't get the point here, could you enlighten me, please?
If identities were cached individually, we could have
load/delete/read/create
handlers that would query the Cache component, and not tie the session's
identity map with the cache.
Why won't you implement it simply as e.g. ezcPersistentCacheIdentityMap
extends ezcPersistentIdentityMap. Should be easy to do. What's wrong
with this?
As far as i'm concerned, i want to use the features of the file-system to
optimize the caching. That means that i don't want to fetch all cached states
at each request.
The list of related objects can be looked up in the same manor as shown
above, but in the $relationMap array:
if ( isseet( $relationMap[$class][$id][$relatedClass] ) )
{
return $identityMap[$class][$id][$relatedClass];
}
return null;
Will that work without specifying the relationName?
Multiple relations to the same class are still a problem I need to
figure out, how to solve. However, shouldn't be that hard, since
ezcPersistentSession already requires you to specify it.
Then you would have this array:
array(
$class = array(
$id = array(
$relatedClass = array(
$relationName = array(
$state
)
)
)
)
Is there any example in eZ Components where a 5 dimension array was/is used?
However, as long as you
Re: [Components] [PersistentObj] writer for definition files
Derick Rethans wrote: On Thu, 26 Jun 2008, Thomas Koch wrote: I found, that PersistentObject could do some part and that it would help, if I could read, manipulate and write ezcPersistentObjectDefinition structures easily. By now we only have a definition writer in DbSchema, but it only takes schemes as input, does not write relations and can not be customized (yet). You can customize this with a text editor, not? Maybe i don't understand either. Did you mean that the database schema *could* be synchronized with the persistent object definitions? Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Input Validation separated from Controller
Hey Joe!
Thanks for, sharing yet another revelant opinion!
Joe Kepley wrote:
I consider it to be very important for clean code to separate the input
validation from any action or logic. This can be best reached by having
different methods for this two tasks.
The actual controller action method should be invoked only with verified
data and should not have to care whether the data is clean. This could
be reached by putting the input data in individual request objects which
are guarentied to contain only verified data:
class myBookingDataConfirmationController
{
public function run( myBookingDataStruct $data )
}
This would be a good thing to do as a subclass, but I don't know if I'd want
to see this on the base interfaces. The stick issue is that what determines
whether or not the data is 'clean' is highly application-specific. There
would need to be an additional layer that defines what data should be
accepted for each controller action.
Given the current spec, though, I think that it would be pretty each to
write custom subclasses for RequestParser, Controller, and an input filter
that implements this behavior.
Actually, the spirit of eZ Components is to not dictate the way you should do
things, or implement your controllers.
Of course, you are free to implement a lower level interface.
I think that we want to keep only what is required in the interfaces, for the
whole pattern to work, but no dictature.
Regards, James.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Input Validation separated from Controller
Hi, thanks for your suggestion!
Thomas Koch wrote:
I consider it to be very important for clean code to separate the input
validation from any action or logic. This can be best reached by having
different methods for this two tasks.
I agree with that (although it is not the most important, i'll come back to that
later).
The actual controller action method should be invoked only with verified
data and should not have to care whether the data is clean. This could
be reached by putting the input data in individual request objects which
are guarentied to contain only verified data:
class myBookingDataConfirmationController
{
public function run( myBookingDataStruct $data )
}
You might be interrested in the new design (which is not implemented in this
controller).
A separate method class is responsible to validate the request data
and to build a myBookingDataStruct from the request. Think of an
ezcInputForm class as an example for such a validator.
Because the validation could fail, we need another method in the
controller:
public function onValidationFailed( myValidator $failedValidator,
ezcMvcRequest $request )
This method is then responsible for showing the error message.
The magic validator should also be provided by the controller, like:
public function getValidator( $protocoll )
I think that it would also be handy for SOAP interfaces to exactly
specify the kind of data that a controller expects.
That is nice and you are free to implement it ;)
As a user of MvcTools since it's early versions, i have a quite good tip to
share: try not to tie in any component in your controllers.
Here a design patten demonstration, i don't know its name, please tell me if you
do.
http://svn.ez.no/svn/ezcomponents/experimental/MvcTools/design/model_controller_loose_coupling_example.svg
Of course, you can make your contoller to depend on
yourInputValidationServiceInterface, and couple UserInput with
yourInputValidationServiceImplementation.
In that case, your controller is loosly coupled with UserInput.
Regards, James.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
Hi Tobias, Thanks for your input!
Tobias Schlitt wrote:
On 06/23/2008 04:50 PM James Pic wrote:
1) Should filter anything?
no
Same as above. Filtering should usually be done in the models, IMO.
Are you sure that persistent object classes should accept invalid values and try
to filter them?
2) Should all the GET/POST variables be mixed together?
yes
No. Or, if necessary, we should offer both: A mixed and single versions.
It might be possible, that both arrays contain the same keys.
Do you mean that input object should be protocol independant by default, but
allow to identify the protocol of a variable?
Input Filters
=
0) Should the component supply an input filter interface?
yes
Not sure here. How would that look like?
interface filter
{
ezcMvcInput public function filter( ezcMvcInput $input );
}
1) Should the component supply input filters?
yes, one in a first stage, then many with tieins
We only have UserInput for this purpose, so this would make 1 tiein.
We might want to make an authentication filter tieing Authentication, which
would identify the user making the request.
And probably other filters like that. (That is why i called it plug-ins)
2) Should the component user handle filtering in his controllers?
yes
Why then an iterface for it? This makes only sense, if we offer
automatic filtering.
We might want to maintain consistency between filters, to provide a
chain-filtering class.
This would require to only select the filters in the controllers, running them
would be encapsulated.
This might also has some testing benefits ...
Output Filters
==
1) Should the component supply input filters?
yes, one with HTML/Tidy in a first stage, then with tieins
Why this for input?
My bad, thanks!
2) Should this filters be pluggable in the view-manager?
no
Where else will they be plugged then?
Actually, it could not be plugged at all, and directly used by the user *after*
the view-manager returned the response strings.
On the other hand, i'm generally for plug-in systems, i think its really nice
to test.
Routing
===
0) Which routed should be developped first? Url, Tree, Regexps, Assertions
(railish) ?
Something without a tiein. I think railish and regex sounds like a good
start.
View-manager
0) Should the view-manager implement the same routing system as the router?
What are the other options?
1) Should another object be used to factorized processes that are common the
the input and the view-router?
What do you imagine here?
If the user should develop the router with the same logic than the view-manager,
maybe we want to have only one router, that decides which controller *and*
view-handler to use.
View-handlers
=
PhpViewHandler
--
0) How should view methods be implemented?
In factories/singletons, it should be easy to port to Template extensions
Don't really get this question.
We might need some view-generation methods, like we would use template
extensions.
How to implement this is PhpViewHandler?
Regards, James.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
Hi, Thanks Kore and Pierre for the input! Pierre Minnieur wrote: Derick Rethans schrieb: On Tue, 24 Jun 2008, Kore Nordmann wrote: On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote: Hi, this is the updated current points to discuss. Feel free to comment or add any ;) HTTP Request Parser === Reminder: the request parser creates the abstract input object. 0) Should it allow plugins? no 1) Should filter anything? no 2) Should all the GET/POST variables be mixed together? yes GET variables should be used for view selection, or maybe selection of the data to display, while POST data should be used for modifications. I wouldn't like that those semantic differences between thse two data arrays are lost in the request parser. That is a very good point. I definitely agree with this. I definitively aggree with you. I'd also suggest to use more of the HTTP protocol available request methods, e.g. PUT for additions/creations and DELETE for drops/removements. This would allow to reuse the same route with four different actions, just by switching the request methods. Problem, we want protocol abstraction, and we want protocol dependant variables. All i can think of filling $input-method with the request parser, but depending on that in the controller is definitively not something we want to do. So, we could specify our own methods, that would be translated in the view-handler and request parser. This way, we could use restfull interface transparently from the protocol. Any suggestion? Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
Derick Rethans wrote: On Tue, 24 Jun 2008, Kore Nordmann wrote: On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote: Output Filters == 2) Should this filters be pluggable in the view-manager? no IF we support output filters, they must be pluggable. Hardcoded filters are imho a no-go. Sure, but the thing is *where* they are pluggable I think here. James, can you clarify? I though that we could use a list of filter objects in the view-manager constructor. Because the view-manager wraps around the view-handlers, it could either be fed into the view-handler, either be used at the view manager level. View-manager 0) Should the view-manager implement the same routing system as the router? How could that work? I don't think the view routing will be URL based in most cases, but just based on the provided view structures. Not sure if some basic general implementation is useful here... In the discussion document we list different views: template, php and json. The view-manager should be free to use the input and output objects to figure which view-handler to use? Regards, James -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] [MvcTools] Protocol abstraction levels
We want protocol specific variables in the protocol specific view-handler. That means, that the request parser should take some variables and put it somewhere for the view-manager later. OPtions we could think of: - add protocol specific variables in the input object, - make two input objects, a raw input object and a protocol abstract input object Thanks in advance for your input! Regards, James -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
Derick Rethans wrote: On Fri, 20 Jun 2008, James Pic wrote: Kore Nordmann wrote: - (HTTP) redirects are also just some view structure, which is returned by the controller, and the view actually performs the proper action depending on the context. Do we want the controller to set HTTP headers in the output object? I'd say that the view-manager should take care of figuring the response code by itself. Yes, I think this should be up to the view/view manager. How do we want that standartized for the output object? Here is a short list of proposals: - $output-status: status identifier, like OK, FAIL, REDIRECT ... - $output-redirect: the redirect object, with variables that should be sent and the controllr name - you-name-it However, we might want to standardize some common UI needs, like with a list of user-messages or something like this: sorry, you don't have the permission to do something. Sorry, please try again later ... Yes, perhaps - although those will never show for normal redirects obviously. What do we want? Here is a short list of proposals: - A sort of ArrayObject in $input-messages, that would contain ezcMvcMessage, - $input-locale, that would contain the locale string, - $input-user, that would contain the user object that is doing the request, - $input-protocol, that would contain a protocol identifier, you-name-it ... Filters can be set on the controller, which are called first and work on the input - modify, action being run at all ... Callbacks? Or a filter configuration? How deep do we want this? I think that when adding a filter to a controller/default controller, they should be callbacks to other classes/methods. This allows us to provide filters in tie-in components (such as for authentication/identification). Callbacks or filter-objects directly? I ignore how you want to do this, may you supply a high(system)-level example please? The user object should be accessible in the view as well, to allow for anonymous/authenticated. Do we want a user interface or something like that? (to make the code portable and testable) Not sure what you mean here, could you provide an example? Me neither, yet, I'll come back on this later ;) (for certain tieins) Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
Hi, Kore Nordmann wrote: I just copied the document from google docs, only applying some reformatting. So that the contents will definitely need some refactoring... On Fri, 2008-06-20 at 14:22 +0200, James Pic wrote: Kore Nordmann wrote: - Controllers only return some view structure, which may contain semantic information about the data to display or information about the template to use. Did you mean: may *not*? No. The key point of dispatching the view structures in the view handler are the smatics of information returned by the controller. For example the controller may return a fooUserStructure, so that a special template could be used to display the user information. Mind to show a little example please? - (HTTP) redirects are also just some view structure, which is returned by the controller, and the view actually performs the proper action depending on the context. Do we want the controller to set HTTP headers in the output object? I'd say that the view-manager should take care of figuring the response code by itself. No, no protocol specific stuff in controller at all. The key point of this is, that the controller returns something, and the view decides to do a redirect because of the provided view structure. The same for error codes, or whatever. Ok, i understand your point. See my suggestion on the reply to Derick. Request Parser == The user object should be accessible in the view as well, to allow for anonymous/authenticated. Do we want a user interface or something like that? (to make the code portable and testable) I don't think we should specify up to this point. It entirely depends on the view structures you pass back from the controller. Like the first example shows there may be big differences in what users might want there. And it is trivial to provide some application dependant user view structure. Also we said, that we want to include the (unauthorized, unvalidated) in the input strucutre, defined by the request parser and pass this structure also to the view - so the information will probably be available somehow... I agree that we need to ettofate the input structure, mind to add/comment stuff to/in the list that i sent as a reply to Derick please? Thanks for your enlighting feedback! Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
Kore Nordmann wrote: - Controllers only return some view structure, which may contain semantic information about the data to display or information about the template to use. Did you mean: may *not*? - The view router decides on base of that, what view to actually use. - (HTTP) redirects are also just some view structure, which is returned by the controller, and the view actually performs the proper action depending on the context. Do we want the controller to set HTTP headers in the output object? I'd say that the view-manager should take care of figuring the response code by itself. However, we might want to standardize some common UI needs, like with a list of user-messages or something like this: sorry, you don't have the permission to do something. Sorry, please try again later ... Request Parser == Filtering for common actions on every request, for example checking for authentication and sessions. Should the request parser identify the user making the request? I though that we decided to do this in the controller. Filters can be set on the controller, which are called first and work on the input - modify, action being run at all ... Callbacks? Or a filter configuration? How deep do we want this? filter chain. It is also useful to do on output, for example to gzip or run http tidy and strip out whitespace. The actions should have access to the request data, for example to render links to the app back etc. The request parser should not do user identification, this belongs in the controller. The user cannot be authorized on the request level, as you'd need some kind of model / backend to validate the provided data. The user data of course needs to be extracted at this stage and provided to the controller. The user object should be accessible in the view as well, to allow for anonymous/authenticated. Do we want a user interface or something like that? (to make the code portable and testable) Uploaded files should be handled in the request parser and for example be provided as list of files names in the input object. The Tree component could be part of a router tiein. Things we can provide: - Request parsers for HTTP (with files), mail (with attachments), IM - E-mail routing example like bugzilla, where some specific parts map to the URL. - Controller provider as a tutorial, perhaps with a base code generator. - Model example with PersistentObjectTiein. - A base router, a normal one, one bound on Url, one on the Tree, one that looks like rails (like jetfuel), one based on regular expressions. - A MvcTemplateTiein, as well as a basic PHP view, simple JSON / XML views just encoding the view structures - The router constructs a Url object as part of the input, which then can be used by the action to generate links to other controllers/actions - including a template function for this. Sebastien will suggest a way to use assertions in the router and the view-manager. Regards, James -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] console tools for ezc
Hello everybody, You are suggesting a component that would tie all other components in? With ConsoleTools, sounds like a usefull bit of a framework ... In that case, CLI scripts should respect the same architecture, therefore factorization is possible and it is probably a good idea to talk about it now, particularely if you count all the testing that has to be done, Maybe we should have one CLI tool, allowing to run different tasks of different categories with arguments. Tasks could be objects implementing a task interface, which would provide all that is needed (arguments, input, output, action ...). This might allow, in an efficient way, to actually improve ConsoleTools, letting the user to program his tasks and not bother about the UI. This enhancement could also allow making profile objects (again, by implementing a profile interface), which would contain default values. For example, you probably don't need to use several db schemas for most projects, its path and format could be in a profile, making these options *not* mandatory. Thomas Koch wrote: commandline tools in eZComponents = - scripts are executable, without suffix (.php) and start with ezc-COMPID-, where COMPID specifies the component they belong to. The COMPID can be a shortcut like dbschema for DatabaseSchema. With UnitTest, i don't mind having not having shortcuts to components because i use a bash shell that has tab-completion. - The console component provides a library of option definitions, which can be reused by all components. Furthermore every component can have it's own library. If the component depends on another component (like PO and DbSchema on DB) then it may reuse the options library of that component. Example: The Db library provides the option dsn, which is useful for DbSchema and PO too. Applications build on top of ezc are free to reuse all option libraries. This concept of inheritance convincts me. - More thoughts must be spend on how to automatically document scripts on the website and in man pages. Good point, for Task interfaces ;) Where to place scripts? === There has been a thread on where to place scripts: http://thread.gmane.org/gmane.comp.web.ezcomponents.devel/2890 The options 1. --forget it -- 2. Make a scripts directory in the src dir of a component + script together with the component where it belongs - can add (optional) requirements to the component 3. Make a new scripts component for each component named ezcComponentNameScripts + Nice handling of requirements - Lots of components On the other hand, each component could ship their own tasks. Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 7475 - /experimental/MvcTools/design/design.txt
Author: jpic Date: Mon Mar 3 00:42:23 2008 New Revision: 7475 Log: - Closed and removed delegate most high-level mechanisms to the router?, as requested by Thomas Nunninger - who submitted the idea. Modified: experimental/MvcTools/design/design.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Mon Mar 3 00:42:23 2008 @@ -263,40 +263,6 @@ } } -Delegate most of the high-level mechanisms to the router? -- - -The following snippet shows the API calls necessary in the user's public -script, in that case :: - - ?php -$parser = new ezcMvcExampleRequestParser(); - -$input = $parser-createInput(); - -$router = new ezcMvcExampleRouter(); -$output = $router-run( $input ); - -//$viewManager = $router-getViewManager( $output ); -$viewManager = new ezcMvcExampleViewManager(); - -// Creates the response and sends it to the client. -$viewManager-handle( $input, $output ); - -Or even :: - -?php -$parser = new ezcMvcExampleRequestParser(); - -$viewManager = new ezcMvcExampleViewManager() - -$router = new ezcMvcExampleRouter( -$parser, -$viewManager -); - -$router-run(); - Open issues === @@ -319,6 +285,9 @@ Controllers have a method looking like : run( ezcMvcInput $input ) It's up to the controller to figure it's action using $input. + +Special considerations +== Shipping of example-implementations --- -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
Re: [Components] MVC design draft
Derick Rethans wrote: On Sat, 23 Feb 2008, James Pic wrote: Thomas Nunninger wrote: Am Freitag, 22. Februar 2008 schrieben Sie: Thomas Nunninger wrote: - I'm still not sure if we need controller multiplicity at all. I guess, it's a problem of my limited phantasie/experience as I can't imagine a situation where I need it. But if we have only one controller, we only have one output - I guess, this will reduce complexity. The only situation, I can imagine you could use it, is a normal portal web site, where you have the main content area and e.g. left/right a menu, some info boxes, ... that are content independant. But I wouldn't use multiple controllers here because this is protocoll/interface depending: you want to have a menu in the HTML frontend but perhaps not in the SOAP or whatever interface. In my opinion, you have one request and this request is handled via one controller. (If you have a request that includes several sub-request, you should not handle this via router - that only has the input to decide on the used controller(s) - but in the controller, that can call some sub-controllers/-processes. Can you give a real world example where you know (from the beginning/ the request input) that you need more than one controller? Actually, you'd need one controller and several so-called zones to build the view of the webportal. Don't know how other systems solve that. In eZ Publish those zones are just some templates that are included in page_layout.tpl. Things like tree menu or a box with latest news are build via template functions that fetch and represent the data. You can argue that this is a little bit against strict MVC as there is some logic inside the templates. But it is somehow intuitive. Also you do not need to touch the core of your application or change some configs if you want to add a new box/zone. That's exactly what i'm talking about. The other problem with zones is that their business-logic is limited to what the template is allowed to use. Wouldn't it make sense for the actions to make sure those zones end up in the output object? the output object itself can just as well be a container. Instead, shouldn't the view-manager make sure that the zones end up in the view ? Regards -- James Pic -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] MVC design draft
Hello everybody,
I fixed consistency between design and requirements docs, and merged our latest
conclusions.
http://svn.ez.no/svn/ezcomponents/experimental/MvcTools/design/requirements.txt
http://svn.ez.no/svn/ezcomponents/experimental/MvcTools/design/design.txt
Also, please give your opinion about the following issues, which should be fixed
before the design becomes final.
Delegate most of the high-level mechanisms to the router?
-
The following snippet shows the API calls necessary in the user's public
script, in that case ::
?php
$parser = new ezcMvcExampleRequestParser();
$input = $parser-createInput();
$router = new ezcMvcExampleRouter();
$output = $router-run( $input );
//$viewManager = $router-getViewManager( $output );
$viewManager = new ezcMvcExampleViewManager();
// Creates the response and sends it to the client.
$viewManager-handle( $input, $output );
Or even ::
?php
$parser = new ezcMvcExampleRequestParser();
$viewManager = new ezcMvcExampleViewManager()
$router = new ezcMvcExampleRouter(
$parser,
$viewManager
);
$router-run();
Thomas, can you give some arguments about your idea if you want to keep it
please ?
Else, we have another use-case, which follows.
Delegate most high-level calls to the user?
---
::
#0 Invocation of a request-parser
$parser = new ezcMvcExampleRequestParser();
#1 Creation of the abstract input
$input = $parser-createInput();
#2 Invocation of a router
$router = new ezcMvcExampleRouter();
#3 Creation of the controller
$controller = $router-createController( $input );
#4 Creation of the abstract output
$output = $controller-run( $input );
#5 Invocation of a view-manager
$viewManager = new ezcMvcExampleViewManager();
#6 Creation and send of the response
$viewManager-handle( $input, $output );
For testing/debugging purposes, it's possible to get the generated response
body and header individually::
#6.1 Create the response body
$viewManager-createResponseBody( $input, $output );
#6.2 Create the response header
$viewManager-createResponseHeader( $input, $output );
Of course, it's possible to implement MvcTools in an OOP way instead of a
procedural way, like for every component::
class myMvcRunner
{
public function run()
{
$parser = $this-createParser();
$input = $parser-createInput();
$router = $this-createRouter();
$controller = $router-createController();
$output = $controller-run( $input );
$viewManager = $this-createViewManager();
$viewManager-handle( $input, $output );
}
protected function createParser()
{
// mechanisms ...
return $parser;
}
protected function createRouter()
{
// mechanisms ...
return $router;
}
protected function createViewManager()
{
// mechanisms ...
return $viewManager;
}
}
We should choose one of those three possible implementations.
I prefer the second one because i think that it makes classes to be less
dependant : more testable.
Should the MVC implementation take care of actions/sub-controllers?
---
Currently :
Controllers have a method looking like : run( ezcMvcInput $input ) It's up to
the controller to figure it's action using $input.
Kore proposed the the controller implement one method per action.
Kore, can you please elaborate on your current position ?
Definition of the ezcMvcController interface
The description and definition of the ezcMvcController interface should be
reworked. The expected behaviour and API of classes implementing this
interface should be described in more details.
Currently, controllers implement one method::
ezcMvcOutput public function run( ezcMvcInput $input )
Of course, this depends on delegating selection of the action to the controller.
Should the router be selected by a router manager?
--
Currently, Tobias and I had chosen :
The router could be selected by a router-manager. In that case, some routing
mechanism should be in the router manager. Router-manager shouldn't be
implemented, routers should be factorized instead.
Please agree or argue :)
--
James Pic
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
[svn-components] 7468 - /experimental/MvcTools/design/design.txt
Author: jpic Date: Fri Feb 29 14:13:11 2008 New Revision: 7468 Log: - Issue about controller multiplicity closed and removed. Modified: experimental/MvcTools/design/design.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Fri Feb 29 14:13:11 2008 @@ -335,12 +335,6 @@ ezcMvcToolsTemplateTiein should include an extension with a function to generate urls for ezcMvcToolsUrlTiein; how to handle this dependency paradox? -Should controllers multiplicity be encapsulated at all ? - - -There is no need to use anything better than a simple associative array for -the list of selected controllers returned by the router at the moment. - Credits === @@ -356,6 +350,6 @@ .. Local Variables: mode: rst - fill-column: 79 + fill-column: 78 End: - vim: et syn=rst tw=79 + vim: et syn=rst tw=78 -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
Re: [Components] MVC design draft
Derick Rethans wrote: On Sat, 23 Feb 2008, James Pic wrote: Gaetano Giunta wrote: - in the end, MVC !== WEB. This is the biggest pain point with all these routing/chaining problems. Mvc was dreamed in a different era, and fits badly to modern-day web apps (unless maybe you do views in javascript). Other things are also staring to show lots of wrinkles, see eg http://www.codinghorror.com/blog/archives/001057.html for a nice insight about keyboard navigation. I don't understand what you mean, doesn't that strictly depend on the view ? Very good article and the comments are even better btw. I think what he is trying to say is that MVC isn't really meant as a pattern for web applications. It works much better in longer running GUI apps where none of the overhead (router, controllers) have to be reloaded on every request (action). Isn't that what Mongrel, the HTTP server in Ruby for Rail does ? I agree that's a good idea but maybe it should be part of another component ? -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 7460 - in /experimental/MvcTools/design: design.txt requirements.txt
Author: jpic Date: Wed Feb 27 16:30:37 2008 New Revision: 7460 Log: - Fixed inconsistencies between requirements and design docs, - Removed controller multiplicity, - Added the new use-case. Modified: experimental/MvcTools/design/design.txt experimental/MvcTools/design/requirements.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Wed Feb 27 16:30:37 2008 @@ -1,7 +1,7 @@ eZ component: MvcTools, Design ~~ -:Author: James Pic, Kore Nordmann, Thomas Nunninger +:Author: James Pic, Thomas Nunninger, Tobias Schlitt :Revision: $Rev$ :Date: $Date$ :Status: Draft @@ -28,41 +28,42 @@ object that the controller returns. Beside these concrete classes a collection of interfaces will be provided for -routing, request-parsing, view-managing and view-handling. This will allow the -user of this component to build his own MVC_ on basis of the components +routing, request-parsing, view-managing and view-handling. This will allow +the user of this component to build his own MVC_ on basis of the components buildingblocks and to adjust it to his needs. Very basic implementations of these interfaces will be shipped with the component, that can be used for very basic applications and are mainly meant -as reference implementations. In future tie-ins with other eZ Components might -be provided, that ship with more advanced impelementations. +as reference implementations. In future tie-ins with other eZ Components +might be provided, that ship with more advanced impelementations. Layers == The component is devided into 4 layers: -The request parsing layer is represented by the ezcMvcRequestParser interface. +The request parsing layer is represented by the ezcMvcRequestParser +interface. An instance of a implementing this interface is responsible for parsing an incoming request and creating an instance of ezcMvcInput from it. This object will encapsulate the complete request data, independent from the protocol and format used for the request. The routing layer, represented by the ezcMvcRouter interface, is in charge of -selecting the correct controller(s) and the view manager to handle the -request, based on the ezcMvcInput object it received. +selecting the correct controller to handle the request, based on the +ezcMvcInput object it received. Controllers represent the third layer. At this level: Classes process the -request, based on the ezcMvcInput object they received, and select the data to -be used to create a response. Controllers only accept an instance of +request, based on the ezcMvcInput object they received, and select the data +to be used to create a response. Controllers only accept an instance of ezcMvcInput as input and and are responsible for returning an instance of ezcMvcOutput, encapsulating all data necessary to render the response. -View management is the final layer, which is based on the incoming ezcMvcInput -object and the ezcMvcOutput object created by the controllers. An instance of -a class implementing the ezcMvcViewManager interface uses one or more -instances of ezcMvcViewHandler to create the actual response and to send it to -the client. +View management is the final layer, which is based on the incoming +ezcMvcInput object and the ezcMvcOutput object created by the controllers. +An instance of a class implementing the ezcMvcViewManager interface uses one +or more instances of ezcMvcViewHandler to create the actual response and to +send it to the client. Classes === @@ -102,24 +103,16 @@ A class implementing this interface is in charge of using an instance of ezcMvcInput to select one or more controllers to run them and collect their -output (in form of ezcMvcOutput objects). In addition, it will select an -implementation of ezcMvcViewManager, instantiate it and submit the collected -responses to be handled by it. +output (in form of ezcMvcOutput objects). Methods:: /** - * Instanciate a router, parses input and selects the controllers and - * view-manager. - */ - ezcMvcRouter public function __construct( $input ) - - /** - * Returns the list of controllers. - * - * @see Encapsulate controller multiplicity ? - */ - ? public function getControllers() + * Returns the controller for this request. + * + * @return ezcMvcController + */ + public function createController( $input ) ezcMvcViewManager - @@ -132,37 +125,45 @@ Methods:: /** - * This method should use the list of controllers, run it, select the view - * handlers and send the response to the client. - * - * @param $controllers array|object Array of controllers or an object - * wrapping them ? - * @see Encapsulate controller multiplicity
[svn-components] 7461 - /experimental/MvcTools/design/design.txt
Author: jpic Date: Wed Feb 27 16:46:30 2008 New Revision: 7461 Log: - Fixed a bug in the use-case Modified: experimental/MvcTools/design/design.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Wed Feb 27 16:46:30 2008 @@ -214,7 +214,7 @@ $controller = $router-createController( $input ); #4 Creation of the abstract output - $output = $controller-createOutput(); + $output = $controller-run( $input ); #5 Invocation of a view-manager $viewManager = new ezcMvcExampleViewManager(); -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
Re: [Components] MVC design draft
Hi Kevin, Thanks for your feedback ! Kevin Waterson wrote: On Thu, 2008-02-21 at 10:56 +0100, Thomas Nunninger wrote: - I'm still not sure if we need controller multiplicity at all. I guess, it's a problem of my limited phantasie/experience as I can't imagine a situation where I need it. But if we have only one controller, we only have one output - I guess, this will reduce complexity. Please allow me to show my newbness and suggest a scenario. If I have a controller to handle loading, then need to have that method load another (admin) router/controller how would this be done? eg: Admin page is loaded. Then select from menu to load admin panel for blog and then for edit_blog_entry. You could either use ajax and use one request per controller. But you could load all the controllers at once for a client-level safe interface - if we implement controller-multiplicity. Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] MVC design draft
Hi Thomas, Thanks for your revelant work ! Thomas Nunninger wrote: - I'm still not sure if we need controller multiplicity at all. I guess, it's a problem of my limited phantasie/experience as I can't imagine a situation where I need it. But if we have only one controller, we only have one output - I guess, this will reduce complexity. The only situation, I can imagine you could use it, is a normal portal web site, where you have the main content area and e.g. left/right a menu, some info boxes, ... that are content independant. But I wouldn't use multiple controllers here because this is protocoll/interface depending: you want to have a menu in the HTML frontend but perhaps not in the SOAP or whatever interface. In my opinion, you have one request and this request is handled via one controller. (If you have a request that includes several sub-request, you should not handle this via router - that only has the input to decide on the used controller(s) - but in the controller, that can call some sub-controllers/-processes. Can you give a real world example where you know (from the beginning/ the request input) that you need more than one controller? Actually, you'd need one controller and several so-called zones to build the view of the webportal. If that's what you mean, why not abstract zones from other controllers making it all implement the same interface ? This should allow more flexibility and re-usability ... Basic case : 0) Client requests cart[add]=123main[ctrl]=browse_itemsbrowse_items[sort]=price 1) Request parser makes an input object from this, which has the same infos. 2) Router selects controllers : cart, browse_items and dynamic_menu. 3) Each are run and there are 3 output-objects. 4) The view-manager parses templates with the output-objects and creates the response. Ajax case : 0) Client requests : main[ctrl]=cartcart[remove]=123cart[quantity]=3 1) Request parser makes an input object from this, which has the same infos. 2) Router selects controller : cart 3) cart controller is run and the output object is there. 4) The view-manager parses the templates with the output objects and creates the response. The soap case is indeed pretty much like the ajax case because it has one single controller. If multiplicity must be encapsulated, i don't think that it's in a decorator controller, what's your idea ? .mutt/tmp/mutt-paloma-1000-6427-104 19,1 Top :set nonumber controller, what's your idea ? Encapsulate controller multiplicity to avoid the overhead when only one is used ? - Regarding the router/view manager: If I understood correctly, a view manager is protocoll-dependant. On which base could the router decide to fetch a view manager? If I'm correct, it has the abstract input object only. I remember that Kore pointed this. Could this be solved by using input *and* output objects in the view-manager to select the handlers ? I fixed the design docs. Regarding this issue and the question about the need of controller multiplicity: perhaps we do not need a view manager but only view handlers? If GET[format] = pdf, for example, isn't it the responsability of the view-manager to select the pdf view-handler ? Open issues === Should the router be selected by a router manager? -- The router could be selected by a router-manager. In that case, some routing mechanism should be in the router manager. Router-manager shouldn't be implemented, routers should be factorized instead. I don't see why there should be 2 routers for one same protocol either, although this obviously seem a correct design pattern. In the rare cases where several routers should be managed, this can be done in the index.php file for example, as a temporary solution before factorization. Is the router protocol dependant? I thought, only the input parser and the view handler should be. Rereading the documentation, I see, that you talk about an ezcMvcUrlUserInputRouter in the example. Is this really neccesary? Actually, ezcMvcUrlUserInputRouter is just a router that *could* come with ezcMvcUrlUserInputRequestParser. We have not though of abstracting the protocol at the router-level afaik, that's a good point. Good day and thanks again, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 7422 - /experimental/MvcTools/design/design.txt
Author: jpic Date: Thu Feb 21 14:49:20 2008 New Revision: 7422 Log: - Input object should be accessible to the view-manager. Idea by Kore. Modified: experimental/MvcTools/design/design.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Thu Feb 21 14:49:20 2008 @@ -121,11 +121,6 @@ */ ? public function getControllers() - /** - * Returns the view-manager. - */ - ezcMvcViewManager public function getViewManager() - ezcMvcViewManager - @@ -144,21 +139,21 @@ * wrapping them ? * @see Encapsulate controller multiplicity ? */ - void public function handle( ? $controllers ) + void public function handle( $input, ? $controllers ) /** * Create and return the response string. * * Returns a string or an ezcMvcResponseBody ? */ - ? public function createResponseBody( ? $controllers ) + ? public function createResponseBody( $input, ? $controllers ) /** * Create and return the response header variables. * * Return an array of key=values or an ezcMvcResponseHeaders ? */ - ? public function createResponseHeader( ? $controllers ) + ? public function createResponseHeader( $input, ? $controllers ) ezcMvcViewHandler - @@ -228,10 +223,10 @@ $controllers = $router-getControllers(); // For example, an instance of ezcMvcTemplateHtmlViewManager -$viewManager = $router-getViewManager(); +$viewManager = new ezcMvcTemplateHtmlViewManager(); // Takes care of running the controllers and rendering their results -$viewManager-handle( $controllers ); +$viewManager-handle( $input, $controllers ); Attempt of representing a common use case, assuming classic HTML over HTTP : @@ -240,8 +235,7 @@ widget[action]=addwidget[id]=3menu[selected]=widget 1) $router can be used to fetch a set of controllers : myMvcWidgetController and myDynamicMenuController. -2) $router can be used to fetch the view-manager : - ezcMvcTemplateHtmlViewManager. +2) Instanciate an ezcMvcTemplateHtmlViewManager. 3) The view manager runs both controllers, and processes two templates using the controllers resulting output object along with ezcMvcTemplateHtmlViewHandler : menu.tpl, widget.tpl -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7420 - /experimental/MvcTools/design/design.txt
Author: jpic Date: Wed Feb 20 11:51:08 2008 New Revision: 7420 Log: - Clarified ThomasN suggestion title. Modified: experimental/MvcTools/design/design.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Wed Feb 20 11:51:08 2008 @@ -252,8 +252,8 @@ replaced by menu.tpl and widget.tpl. 3.2) The view-manager can send HTTP-headers. -Encapsulate controller multiplicity outside the router? +Delegate most of the high-level mechanisms to the router? +- The following snippet shows the API calls necessary in the user's public script, in that case :: -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7419 - /experimental/MvcTools/design/design.txt
Author: jpic Date: Wed Feb 20 11:45:41 2008 New Revision: 7419 Log: - Should controllers multiplicity be encapsulated at all ? Modified: experimental/MvcTools/design/design.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Wed Feb 20 11:45:41 2008 @@ -323,6 +323,12 @@ ezcMvcToolsTemplateTiein should include an extension with a function to generate urls for ezcMvcToolsUrlTiein; how to handle this dependency paradox? +Should controllers multiplicity be encapsulated at all ? + + +There is no need to use anything better than a simple associative array for +the list of selected controllers returned by the router at the moment. + .. Local Variables: -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7413 - /experimental/MvcTools/design/design.txt
Author: jpic Date: Tue Feb 19 13:33:59 2008 New Revision: 7413 Log: - Added methods definitions for interfaces. Modified: experimental/MvcTools/design/design.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Tue Feb 19 13:33:59 2008 @@ -73,6 +73,13 @@ The ezcMvcRequestParser interface has to be implemented by classes that will parse a request and create an ezcMvcInput object. +Methods:: + + /** + * Parses the request and creates an input object. + */ + ezcMvcInput public function createInput() + ezcMvcInput --- @@ -89,7 +96,6 @@ This object encapsulates the result of a controller, abstracting from the actual response protocol. The output object will be modelled similar to the input variant, described above. - ezcMvcRouter @@ -100,6 +106,26 @@ implementation of ezcMvcViewManager, instantiate it and submit the collected responses to be handled by it. +Methods:: + + /** + * Instanciate a router, parses input and selects the controllers and + * view-manager. + */ + ezcMvcRouter public function __construct( $input ) + + /** + * Returns the list of controllers. + * + * @see Encapsulate controller multiplicity ? + */ + ? public function getControllers() + + /** + * Returns the view-manager. + */ + ezcMvcViewManager public function getViewManager() + ezcMvcViewManager - @@ -107,6 +133,32 @@ coordinating the rendering of ezcMvcOutput instances into a format acceptable for the response protocol. The rendering itself is done by instances of ezcViewHandler. + +Methods:: + + /** + * This method should use the list of controllers, run it, select the view + * handlers and send the response to the client. + * + * @param $controllers array|object Array of controllers or an object + * wrapping them ? + * @see Encapsulate controller multiplicity ? + */ + void public function handle( ? $controllers ) + + /** + * Create and return the response string. + * + * Returns a string or an ezcMvcResponseBody ? + */ + ? public function createResponseBody( ? $controllers ) + + /** + * Create and return the response header variables. + * + * Return an array of key=values or an ezcMvcResponseHeaders ? + */ + ? public function createResponseHeader( ? $controllers ) ezcMvcViewHandler - @@ -117,6 +169,22 @@ different view handlers and to merge their output to a consistent response string. +Methods:: + + /** + * Create and return the response string. + * + * Returns a string or an ezcMvcResponseBody ? + */ + ? public function createResponseBody( ? $controllers ) + + /** + * Create and return the response header variables. + * + * Return an array of key=values or an ezcMvcResponseHeaders ? + */ + ? public function createResponseHeader( ? $controllers ) + ezcMvcController @@ -151,7 +219,7 @@ $parser = new ezcMvcUrlUserInputRequestParser(); // The parser returns an instance of ezcMvcInput. -$input = $parser-getInput(); +$input = $parser-createInput(); // ezcMvcUrlUserInputRouter implements ezcMvcRouter $router = new ezcMvcUrlUserInputRouter( $input ); -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7410 - /experimental/MvcTools/design/design.txt
Author: jpic Date: Tue Feb 19 12:40:40 2008 New Revision: 7410 Log: Added open-issue about dependencies paradox. Modified: experimental/MvcTools/design/design.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Tue Feb 19 12:40:40 2008 @@ -249,6 +249,12 @@ or should deal as documentation (and therefore reside in the docs/ directory instead of src/). +Tiein components + + +ezcMvcToolsTemplateTiein should include an extension with a function to +generate urls for ezcMvcToolsUrlTiein; how to handle this dependency paradox? + .. Local Variables: -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7402 - in /trunk/ConsoleTools: ChangeLog tests/input_test.php
Author: jpic
Date: Mon Feb 18 15:31:26 2008
New Revision: 7402
Log:
Fixed issue #12561: getSynopsis() bugs when at least 2 options don't have
short-names.
Modified:
trunk/ConsoleTools/ChangeLog
trunk/ConsoleTools/tests/input_test.php
Modified: trunk/ConsoleTools/ChangeLog
==
--- trunk/ConsoleTools/ChangeLog [iso-8859-1] (original)
+++ trunk/ConsoleTools/ChangeLog [iso-8859-1] Mon Feb 18 15:31:26 2008
@@ -6,7 +6,7 @@
(ezcConsoleQuestionMappingValidator) was introduced for this, which extends
ezcConsoleQuestionCollectionValidator and is now used for the
yes-no-question.
- Implemented issue #10791: ezcConsoleTable should implement __toString.
-
+- Fixed issue #12561: getSynopsis() bugs when at least 2 options don't have
short-names.
1.3.2 - Monday 14 January 2008
^^
Modified: trunk/ConsoleTools/tests/input_test.php
==
--- trunk/ConsoleTools/tests/input_test.php [iso-8859-1] (original)
+++ trunk/ConsoleTools/tests/input_test.php [iso-8859-1] Mon Feb 18 15:31:26
2008
@@ -2214,9 +2214,7 @@
);
}
-/**
- * See issue #012561
- */
+// Issue #012561 : getSynopsis() bugs when at least 2 options don't have
short-names.
public function testGetSynopsisLongOptionsWithoutShortNames()
{
$input = new ezcConsoleInput();
--
svn-components mailing list
svn-components@lists.ez.no
http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7401 - in /trunk/ConsoleTools: src/input.php tests/input_test.php
Author: jpic
Date: Mon Feb 18 15:21:49 2008
New Revision: 7401
Log:
Fix issue #012561
Modified:
trunk/ConsoleTools/src/input.php
trunk/ConsoleTools/tests/input_test.php
Modified: trunk/ConsoleTools/src/input.php
==
--- trunk/ConsoleTools/src/input.php [iso-8859-1] (original)
+++ trunk/ConsoleTools/src/input.php [iso-8859-1] Mon Feb 18 15:21:49 2008
@@ -797,7 +797,7 @@
*/
public function getSynopsis( array $optionNames = null )
{
-$usedOptions = array();
+$usedOptions = array( 'short' = array(), 'long' = array() );
$allowsArgs = true;
$synopsis = '$ ' . ( isset( $argv ) sizeof( $argv ) 0 ? $argv[0]
: $_SERVER['argv'][0] ) . ' ';
foreach ( $this-getOptions() as $option )
@@ -907,9 +907,10 @@
$synopsis = '';
// Break after a nesting level of 2
-if ( $depth++ 2 || in_array( $option-short, $usedOptions ) ) return
$synopsis;
+if ( $depth++ 2 || ( in_array( $option-short, $usedOptions['short']
) in_array( $option-long, $usedOptions['long'] ) ) ) return $synopsis;
-$usedOptions[] = $option-short;
+$usedOptions['short'][] = $option-short;
+$usedOptions['long'][] = $option-long;
$synopsis .= $option-short !== ? -{$option-short} :
--{$option-long};
Modified: trunk/ConsoleTools/tests/input_test.php
==
--- trunk/ConsoleTools/tests/input_test.php [iso-8859-1] (original)
+++ trunk/ConsoleTools/tests/input_test.php [iso-8859-1] Mon Feb 18 15:21:49
2008
@@ -2213,7 +2213,36 @@
'Program synopsis not generated correctly.'
);
}
-
+
+/**
+ * See issue #012561
+ */
+public function testGetSynopsisLongOptionsWithoutShortNames()
+{
+$input = new ezcConsoleInput();
+$input-registerOption(
+new ezcConsoleOption(
+,
+set-dericktory,
+ezcConsoleInput::TYPE_NONE
+)
+);
+
+$input-registerOption(
+new ezcConsoleOption(
+,
+set-directoby,
+ezcConsoleInput::TYPE_NONE
+)
+);
+
+$this-assertEquals(
+'$ '.$_SERVER['argv'][0].' [--set-dericktory] [--set-directoby]
[[--] args]',
+$input-getSynopsis(),
+'Program synopsis not generated correctly.'
+);
+}
+
public function testGetSynopsisNewArgumentsSimple()
{
$this-input-argumentDefinition = new ezcConsoleArguments();
--
svn-components mailing list
svn-components@lists.ez.no
http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7382 - /experimental/MvcTools/design/design.txt
Author: jpic Date: Fri Feb 15 12:03:10 2008 New Revision: 7382 Log: Added question about router-manager. Modified: experimental/MvcTools/design/design.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Fri Feb 15 12:03:10 2008 @@ -196,11 +196,19 @@ $router-run(); +Should the router be selected by a router manager ? +--- + +The router could be selected by a router-manager. +In that case, some routing mechanism should be in the router manager. +Router-manager shouldn't be implemented, routers should be factorized instead. + Should the MVC implementation take care of actions/sub-controllers ? Controllers have a method looking like : run( ezcMvcInput $input ) It's up to the controller to figure it's action using $input. + .. Local Variables: -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7374 - /experimental/MvcTools/design/design.txt
Author: jpic Date: Thu Feb 14 14:57:26 2008 New Revision: 7374 Log: Details about I/O objects and the controller interface Modified: experimental/MvcTools/design/design.txt Modified: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt [iso-8859-1] (original) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Thu Feb 14 14:57:26 2008 @@ -64,11 +64,21 @@ This object encapsulates the client-request, abstracting the request protocol. +It's important to separate the object's properties from the request variables +in the class facade. +This class implements Iterator, ArrayAccess and Countable for request-values, +and public properties will be used for the object's variables. + ezcMvcOutput This object encapsulates the controller result, abstracting the response protocol. + +It's important to separate the object's properties from the request variables +in the class facade. +This class implements Iterator, ArrayAccess and Countable for request-values, +and public properties will be used for the object's variables. ezcMvcRouter @@ -88,6 +98,18 @@ This interface has to be implemented by classes that handle rendering one ezcMvcOutput object into one formated (part of the) response string. + +ezcMvcController + + +This interface should be implemented by user's controllers. +Assuming that action-selection should be done within the controller itself : +it should have one public method : run( $input, [ $output = null ] ). + +The controller should be able to use the passed output-object instead of +creating a new one. +Using an existing output-object might require that the output-object implement +controller-level namespacing : this should not be supported. Possible system conceptions === -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7354 - in /experimental/MvcTools: ./ TODO design/ design/design.txt design/requirements.txt
Author: jpic Date: Tue Feb 12 18:23:46 2008 New Revision: 7354 Log: Imported the documents of MvcTools after merging Derick R. requirements. Added: experimental/MvcTools/ experimental/MvcTools/TODO experimental/MvcTools/design/ experimental/MvcTools/design/design.txt experimental/MvcTools/design/requirements.txt Added: experimental/MvcTools/TODO == --- experimental/MvcTools/TODO (added) +++ experimental/MvcTools/TODO [iso-8859-1] Tue Feb 12 18:23:46 2008 @@ -1,0 +1,2 @@ +- confirm that 500 is the correct HTTP response code to use in case of + fallback controller failure. Added: experimental/MvcTools/design/design.txt == --- experimental/MvcTools/design/design.txt (added) +++ experimental/MvcTools/design/design.txt [iso-8859-1] Tue Feb 12 18:23:46 2008 @@ -1,0 +1,183 @@ +eZ component: MvcTools, Design Draft + + +:Author: James Pic, Kore Nordmann, Thomas Nunninger +:Revision: $Rev$ +:Date: $Date$ +:Status: Draft + +.. contents:: + +Scope += + +The scope of this document is to describe the initial design of a component +that provides classes to implement a MVC_ architecture for a web application. + +.. _MVC: http://en.wikipedia.org/wiki/Model-view-controller + +Design overview +=== + +Because of the variaty of protocols and formats that a modern PHP application +should handle, this MVC implementation will provide an abstraction to input +and output of controllers. Besides that, a few tieins will be provided. + +The main classes of this component are ezcMvcInput and ezcMvcOutput, which +are respectively the abstract input object for the controller and the +abstract output object that the controller should return. + +Additionally, a collection of interfaces will be provided for routing, +request-parsing, view-managing and view-handling. + +Layers +== + +The component is basically devided into 4 layers: the request parsing layer +is represented by an interface. An instance of such a class is responsible +for parsing the request and making an abstract input object. + +The routing layer is in charge of selecting the controller(s) and the view +manager, using the abstract input object. + +Controllers are the third layers, at this level : classes process the +request and select the data to use for making the response : controllers +accept the abstract input object and are responsible for returning an +abstract output object. + +View management is the final layer, using on the output and input objects : +the view-manager use the view-handler(s) to create the formatted final +response to send to the client. + +Classes +=== + +ezcMvcRequestParser +--- + +The ezcMvcRequestParser interface has to be implemented by classes that will +parse the request and create an ezcMvcInput object. + +ezcMvcInput +--- + +This object encapsulates the client-request, abstracting the request +protocol. + +ezcMvcOutput + + +This object encapsulates the controller result, abstracting the response +protocol. + +ezcMvcRouter + + +This interface is in charge of using an instance of ezcMvcInput to select the +controller(s) and the view-manager. + +ezcMvcViewManager +- + +This interface has to be implemented by classes that are in charge of +rendering the instance(s) of ezcMvcOutput into a format acceptable for the +response protocol, using view-handlers. + +ezcMvcViewHandler +- + +This interface has to be implemented by classes that handle rendering one +ezcMvcOutput object into one formated (part of the) response string. + +Possible system conceptions +=== + +Encapsulate view handler multiplicity into a view-manager ? +--- + +This will free the router and user-space from rendering tasks, particularely +useful when using several controllers at once. +I think that the component should provide such a class, letting to +concentrate on working on view handlers. + +The following snippet shows the API calls necessary in the user's public +script, in that case :: + + ?php +// ezcMvcUrlUserInputRequestParser implements ezcMvcRequestParser +$parser = new ezcMvcUrlUserInputRequestParser(); + +// The parser returns an instance of ezcMvcInput. +$input = $parser-getInput(); + +// ezcMvcUrlUserInputRouter implements ezcMvcRouter + $router = new ezcMvcUrlUserInputRouter( $input ); + +// An array or list-class with controllers +$controllers = $router-getControllers(); + +// For example, an instance of ezcMvcTemplateHtmlViewManager +$viewManager = $router-getViewManager(); + +// Takes care of running the controllers and rendering their results +$viewManager-handle( $controllers ); + +Attempt of representing
Re: [Components] MVC design draft
Hello everybody, It's good that the link posted by Thomas N. is down because the document's quality was very low (a first try). You'll notice that this document really concentrates on system-conception (high-level and general); because I beleive that I'm bound to fail at real object-conception and implementation questions before working a little more at this stage with everybody :) Feel free to contradict me on that, the document is at an early draft stage anyway. It's attached to this message, and integrates (not brillantly) Thomas N.'s revelant suggestion. Thomas Nunninger wrote: Can you give an example, where it is usefull (at the beginning of request handling) to fetch a set of controllers? Perhaps I'm blind or I'm thinking in a wrong direction, but I can't imagine a situation where I need this. (Of course, you could need re-routing, but I guess, this is the result of the controller. Before running the first controller, I do not know about a second controller.) In some popular MVC-implementations supplied by frameworks, the HTML view is built with a controller and zones. Assuming that the view manager has the mechanism to render the complete HTML body : zones should be abstracted from controllers; making zones to not be dependant and more testable and portable. Note that i haven't though very deep about re-routing yet because i still assume that adding a few methods to the router interface for this will suit the needs, but i can be wrong. The second point is somehow related: you append several outputs to the view manager. I'm not sure, if I like this. I think, there should be one output object. Won't that cause the output object to implement controller-namespace on variables ? If I'd need something like a set of controllers or outputs, I guess, I'd implement a controller container that runs the several needed controllers, and then composes one output object from the several returned output objects. I pretty sure that it's agile to make a list-class for controllers and their outputs, but could you to elaborate please :) Also I think, that I'd put some of your script code in the router's(?) code. I'd write it somehow like this: $parser = new ezcMvcUrlUserInputRequestParser(); // The parser returns an instance of ezcMvcInput. $input = $parser-getInput(); $router = new ezcMvcUrlUserInputRouter(); $output = $router-run( $input ); // For example, an instance of ezcMvcTemplateTieinHtmlViewManager $viewManager = $router-getViewManager( $output ); I think that the router should be able to access the output object when selecting the view manager as well. // Creates the response and sends it to the client. $viewManager-handle(); Or even: $parser = new ezcMvcUrlUserInputRequestParser(); $viewManager = new ezcMvcTemplateHtmlViewManager() Do the requirements allow this or is it the role of the router to select between ezcMvcTemplateHtmlViewManager and ezcMvcPdfViewManager for example, depending on the client request (like GET $pdf = true for example). // ezcMvcUrlUserInputTieinRouter implements ezcMvcRouterInterface $router = new ezcMvcUrlUserInputRouter( $parser, $viewManager ); $router-run(); Won't that cause too much dependencies ? Do we need view management to depend on controller interface or should it depend only on output and input objects ? Thanks a lot for your feedback, revelant suggestions and constructive discussion on IRC Thomas ! Cheers ! -- James Pic /me *hopes* that his message is understandable by english-speakers :) eZ component: MvcTools, Design Draft :Author: James Pic, Kore Nordmann, Thomas Nunninger :Revision: $Rev$ :Date: $Date$ :Status: Draft .. contents:: Scope = The scope of this document is to describe the initial design of a component that provides classes to implement a MVC_ architecture for a web application. .. _MVC: http://en.wikipedia.org/wiki/Model-view-controller Design overview === Because of the variaty of protocols and formats that a modern PHP application should handle, this MVC implementation will provide an abstraction to input and output of controllers. Besides that, a few tieins will be provided. The main classes of this component are ezcMvcInput and ezcMvcOutput, which are respectively the abstract input object for the controller and the abstract output object that the controller should return. Additionally, a collection of interfaces will be provided for routing, request-parsing, view-managing and view-handling. Layers == The component is basically devided into 4 layers: the request parsing layer is represented by an interface. An instance of such a class is responsible for parsing the request and making an abstract input object. The routing layer is in charge of selecting the controller(s) and the view manager, using
[Components] MVC: Final draft of requirements document
Hello everybody ! We are done with a final draft, document attached. I'll post an implementation document first draft tomorrow morning. I also want to thank two very special and talented persons whom have higly contributed : Kore Nordmann and Tobias Schlitt. This document would have never met such a high-quality (to my opinion) without the experience and time that you have shared ! Cheers, James. -- James Pic eZ Component: MvcTools, Requirements :Author: James Pic, Tobias Schlitt :Revision: $Revision$ :Date: $Date$ Target and scope The scope of this document is to describe the requirements for a component providing classes to implement a MVC_ architecture for a web application. This document does not describe the design of the named component, but only summarizes the requirements for it as discussed on the developer mailinglist. Where suitable, design related topics will be touched, but a dedicated design document will follow later, defining APIs, classes and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. Introduction Model-View-Controller (MVC) is a common architecture pattern to implement all kinds of applications using the object-oriented design paradigm. The goal of the MvcTools component is to give users a basis for such architectures for web applications written in PHP 5. The component shall not provide a full-featured implementation of the MVC architecture, but should help users to easily create their own, custom implementation. A good starting point to learn more about MVC is the Wikipedia article: http://en.wikipedia.org/wiki/Model-view-controller Component integration = eZ Components already provide some components that are useful when implementing an MVC. However, one basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through so-called tie-in components. Therefore the mechanisms realized in an MVC component should be that far abstracted, that other components can be tied in and provide only very basic implementations on its own. This also allows users to implement their own mechanisms. The following components have been identified as possible tie-ins: - Template_ (view) - UserInput_ (routing) - Url_ (routing) - PersistentObject_ (models) - EventLog_ (error-handling) - Mail_ (error-handling, view) .. _UserInput: http://ezcomponents.org/docs/tutorials/UserInput .. _Url: http://ezcomponents.org/docs/tutorials/Url .. _PersistentObject: http://ezcomponents.org/docs/tutorials/PersistentObject .. _EventLog: http://ezcomponents.org/docs/tutorials/EventLog .. _Mail: http://ezcomponents.org/docs/tutorials/Mail For each of these components a tie-in component could considered to be implemented at a later stage. This should be kept in mind when desigining the classes/interfaces for the MvcTools component. Design requirements === This section summarizes the requirements regarding the later following design document. I/O abstraction Modern applications often require to deal with different input and output protocols and formats (for example HTTP-GET, HTTP-POST, SOAP for the input part and HTML, PDF, ReST-webservices for the output part). Therefore, protocols input and output formats should be abstracted into dedicated objects, which are not specific to a certain protocoll or format. Controllers will only receive these abstracted data objects without knowledge of the used format/protocol, to allow the re-use of 1 controller with severl different input/output sources. A benefic side-effect relates to controller-testing: Creating input and output mocks and fixtures allows straight-forward TDD. Summary ^^^ - Controllers should not know about the input and output environment but work on abstract objects only. Layers -- The MvcTools component should distinguish certain layers to allow users to easily adjust and replace certain functionality. Therefore, the following requirements have been specified. Controllers process and respond to events, typically user actions, and may invoke changes on the model. In our case, controllers run an action using a single argument: An input-object. A controller returns an output-object, after being run. Another different layer is responsible to select the controller to run and the action to call on it. To create the input-object it requires the so-called input-router. After the controller has been run, the output object is send to the view-manager, which is responsible to select the correct rendering mode for the output protocol/format. Those two layers should be able to use any number of controllers per-request. They handle the client-protocol, so that the controller doesn't have work on raw input data (e.g. GET/POST/...) and does not have to generate any specific
Re: [Components] Framework/MVC component
Hi Kore, Thanks for your feedback, i agree about error-handling. Kore Nordmann wrote: As said earlier I still got issues with two sections. My suggestions: View-management --- The controller returns an abstract output object, which then should be displayed by the view manager. The view manager receives the output object and the abstract request object an can decide on the base of both of them which view handler to use. Example ^^^ 1. The user requests /some/file.pdf 2. The controller generated the data for this. 3. The view manager receives a OutputObject with the data, and knows from the request structure, that a PDF file has been requested. The view manager now select the PDF generator as the view handler and calls the right template for the generated output object. Why shouldn't the view-handler be selected by the router ? Do we want to make input-object fixtures in addition to output-object fixtures to test a view-manager ? I think that the router should select the view-handler, allowing it to not use input-objects. This also seems more natural to me because the view-handler definitively needs the output-object, but could be totaly abstracted from input. Example : 1. The user requests /some/file.pdf 2.1 The router filters input and makes the input-object 2.2 The router selects the controller 2.3 The router selects the view-handler 3. The selected controller runs with the input-object 4. The selected view-handler runs with the resulting output-object In brief, can you elaborate the reasons why you think that input-to-view-handler-selection should not be done by another router please ? Regards, James -- James Pic -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Framework/MVC component
Hi Alexandru and others ! Thanks for your feedback ! Alexandru Stanoi wrote: James Pic wrote: A website has three dynamic zones : main, basket and navigation. We discussed of this with Laurent Jouanneau (creator of Jelix), he decided to make a controller of main and zones for basket and navigation. However, the current requirements involve zone/controller abstraction. So, there should be three controllers : $main, basket and navigation. The input router should select the $main controller, and run basket and navigation anyway. The output-router should use outputs of these controllers to generate : - the layout template, - the main template, - the navigation template, - the basket template. Once the main is inserted in the layout, the new layout should have variables to locate placement for navigation and basket. Result : any combination of templates is possible and controllers did not need to select the template. However I don't really understand everything as it all looks too complex. Only in this last mail I see a practical example with the basket and the navigation zones. It would have been nice to see more of these examples along the way. But looking at this example, I see a kill mosquitos with the cannon approach: why is it so complicated that you need 3 controllers, an input router and output router just to display a template on the screen? Making a controller for the basket or the navigation is not mandatory. You should decide if you want the basket and the navigation to be hard-coded in the view-handler. I'm not sure how your basket works, but it can involve many business-critical checks, the following reasons are valuable in that case : - controllers can be used stand-alone, and (almost) natively re-usable with different protocols, - testing the input-routers, the view-handlers and the controllers can be done separately. Contretly, i'll be asked to make a basket-controller later this year, and to implement a soap server to interface it. This is just a real-world example. Elaborations following ... I don't think that the average web developer knows about things like controller and router. He probably knows how to read input from $_GET, filter the input, run some SQL queries, create a Template object, pass some values to it and voilà! a page is displayed. How would controllers and routers simplify these things, or even how would they help in any way? .mutt/tmp/mutt-paloma-1000-15007-104 22,1 Top routers simplify these things, or even how would they help in any way? I agree that average the developper doesn't need OO or even unit-testing : I made several average-sized projects in totally procedural code and without any test, i can elaborate about the pain i've been experiencing in this three years of maintenance if you want. I think that this component is usefull for at least medium sized projects. So I would like to see the answers to the questions: - why do we need MVC? It's based on three needs : - faster development, - conventions, - faster testing. - how to use MVC? Import your previous routers, controllers or view-handlers if appliable. Use the tieins to concentrate your efforts on the complex parts of a project in a first stage. How to test a router : make the request fixture, make the expected input-object fixture, run the router with the request fixture, assert that the resulting input-object matches the expected-input-object-fixture, assert that the expected view-manager was selected, assert that the expected view-manager was selected. How to test a controller : make the input-object fixture, make the expected output-object fixture, run the controller with the input-object fixture, assert that the result matches the expected-output-object-fixture. How to test a view-manager : make the output-object fixture, make the expected response fixture, run the view-handler and assert that the result matches the response-fixture. - what benefits does MVC have? This sounds like agile development of really re-usable classes to me. That is *my* point of view, and i'm quiet a newbie in *zen* development (i've made my proofs as a debugger-warrior though). I've lost more hairs on a couple of projects, than with the thousands of lemmings i've managed in my life. In an unordered and unsorted list : - convention on testing, - convention on architecture, - faster with tieins, - allowing to concentrate the most challenging parts of a project, - re-usable ... -- James Pic -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Framework/MVC component
Hi Kore and everybody ! I tryed to merge your requirements. New document : http://xrl.us/bfe6f Diff: http://xrl.us/bfe53 A few questions remain : 0) About the I/O routers tieins, it's up to the user to decide wheter to use URL-mapping or URL-generation/parsing. Which should the tiein use ? It's clear that URL-mapping will be *slightly* more complex and suit high-loads, though URL-generation/parsing is *slightly* simpler and suits sites without high-loads (intranets ...). I like both ideas, i think that both tieins should be supplied, though we should decide of one in a first stage. 1) Should controllers have the hand on views ? This should be up to the user, it's possible to add a template_path variable to the output object to be used by the output-router. But again, should the output-router Template-tiein expect the controller to return a template_path ? I think that it's better to demonstrate how it's possible to do without having the controller to decide of the template, using a controller-template mapping. Let me define a rather common use-case. A website has three dynamic zones : main, basket and navigation. We discussed of this with Laurent Jouanneau (creator of Jelix), he decided to make a controller of main and zones for basket and navigation. However, the current requirements involve zone/controller abstraction. So, there should be three controllers : $main, basket and navigation. The input router should select the $main controller, and run basket and navigation anyway. The output-router should use outputs of these controllers to generate : - the layout template, - the main template, - the navigation template, - the basket template. Once the main is inserted in the layout, the new layout should have variables to locate placement for navigation and basket. Result : any combination of templates is possible and controllers did not need to select the template. Thanks Kore Nordmann for the pragmatic review of the requirement document ! -- James is_null Pic. pgpPSsNuFETjX.pgp Description: PGP signature -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Framework/MVC component
Hello everybody, An update of the requirements documents, where i compiled our needs and answered the un-answered questions. Note that we haven't discussed of output yet. Cheers, James. eZ Component: MvcTools, Requirements ~ :Author: James Pic, Tobias Schlitt :Revision: $Revision$ :Date: $Date$ Target and scope The scope of this document is to describe the initial design of a component providing tools for users to implement an extendable and unified MVC_ pattern. Note that if you don't understand a term, you should have a look at the end of this document, section : Clarification of terms`_. There have been questions about the implementation on the ML, let's restrict the discussion to the actual *requirements* for the moment, allowing to decide of the best implementations later. So, the question here: What does everyone need/expect here? Component integration = eZ Components already provide some components that are useful when implementing an MVC. However, one basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through tie-ins. Therefore the mechanisms realized in an MVC component should be that far abstracted, that other components can be tied in and provide only very basic implementations on its own. This also allows users to implement their own mechanisms. I identified the following components to be related here: - Template_ (view), - UserInput_ (routing), - Url_ (routing), - PersistentObject_ (models), - EventLog_ (error-handling), - Mail_ (error-handling). .. _Template: http://ezcomponents.org/docs/tutorials/Template .. _UserInput: http://ezcomponents.org/docs/tutorials/UserInput .. _Url: http://ezcomponents.org/docs/tutorials/Url .. _PersistentObject: http://ezcomponents.org/docs/tutorials/PersistentObject .. _EventLog: http://ezcomponents.org/docs/tutorials/EventLog .. _Mail: http://ezcomponents.org/docs/tutorials/Mail Design requirements === General goals for I/O abstraction - Modern applications often require to deal with different protocols (SOAP, HTTP ...). Therefore, protocol inputs and outputs should be abstracted when programming actions, allowing those to be almost natively portable. A benefic side-effect relates to action-testing. Making input and output mocks and fixtures allows straight-forward test-programming. Summary ^^^ - controllers should (almost) natively support multiple protocols, - making input and output fixtures to unify controller testing. Error-handling -- Actions should be free to fail for any reason (input not viable, requested data doesn't exist ...). Failures should be reported to the user, so that the user can understand and either try again later or with different input. Some failures can have critical consequences or causes, which might interrest some actors; thus a report should be sent. The visitor requires a verbose error message to be displayed in an arbitary controller, wheras project-actors that will be notified (if any) require a technical report. Summary ^^^ Actions should be able to cast an error specifying, at once : - the verbose error message, - the non-verbose error message or id, - the target action to bundle the error with, - wheter actors should be notified or not. An EventLog_ + Mail_ tie-in should be supplied. .. _EventLog: http://ezcomponents.org/docs/tutorials/EventLog .. _Mail: http://ezcomponents.org/docs/tutorials/Mail Routing --- It's the key to I/O abstraction. Requests are issued to a router object, which handles the input abstraction. Then, it should select an action and run it using the abstracted-input. Actions result in an abstracted-output, like a set of variables; the router use it to make the final response. Each protocol requires a different I/O abstraction process : each protocol require a router. Using a router layer between the action and the client can seem natural, routers abstract the local-network into one external address and set of ports. Being the first layer meeting user-input, it should handle filtering before producing the abstract-input. Being the router, it has the keys to any actions, thus it should allow action to re-route the user-input to another action. Summary ^^^ Routers should be able to : - filter input, - make an abstract-input object, - run the requested action using the abstract-input as argument, - which should result in an abstract-output object, - make the response using the abstract-output object, - directly send the response. - be asked by a controller to re-route the request to another action. - be accessible from any action. This allows one-router-per-protocol. A UserInput_ + Url_ tie-in should be supplied for HTTP : it should implement ezcTemplateCustomFunction and provide Template-functions to making viable-urls in templates. However, overloading
Re: [Components] Framework/MVC component
Hello everybody ! Tobias Schlitt wrote: Hi! On 01/25/2008 12:34 PM Gaetano Giunta wrote: As far as I am concerned, the C+V should be flexibile enough (or abstracted/away enough) to allow building with extreme ease servers that support different calling-conventions (eg rest,soap,xmlrpc,plain old html etc) for the same functions. This means: - allowing the input abstraction layer to decide upon current module/action to be executed based on any combination of http headers, get params and request payload I think this is the thing we need to abstract: The input abstraction should abstract from the GET/POST/... data, headers and things, so that the router can decide which controller to use. Or did I get you wrong? Controllers should use an abstracted input object. The input object should be buildable from differrent request protocols. - allowing the view to be used for rendering output to be tied either to the action in execution or not (eg tied to the module or to something esle) I don't really get this one. Could you elaborate some more here, please? This looks like controller re-routing to me. - allowing to have actions specified as either one class (php file) per action or as one method per action This could depend on the router implementation, I think. However, I personally would favor to have it defined once, for consistency. It should be quiet straight-forward to make a controller using classes for actions anyway. sorry if this is too low-level for this discussion, I have been wrestling with symfony for 3 days right now, and while it looks very nice and friendly in the beginning, its turning out to be way harder than expected to extend its controller Your input is really valuable. It would be great if you could invest some more time to discuss the requirements and design of this stuff with us here. :) Thank you very much for your revelant feedback, see you later on the ml, regards, James. pgpP0IV7wmwTp.pgp Description: PGP signature -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] comp. proposal : MvcTools
Hello everybody, note that i have a deadline for this (March) so i'll be doing a PoC until then for sure - in case the proposal in refused. Some more (messy) ressources on cornershop.devangels.net, click browse source, trunk, resources. The additionnal ressources include a discussion with laurentj, creator of Jelix, which is the most interresting. Cheers, James. -- James Pic GPG Key : 13185F50x8 / AEE2 CC15 8FF8 339C 23AC 5A91 491B 1638 1318 5F58 Downloadable on http://jamespic.com/pubkey.asc eZ Component: MvcTools, Requirements ~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ Introduction Description --- As of 2008, PHP6 is released and ezComponents provide PersistentObject and Template. These components are efficient when used in the Model and the View layers of an MVC application. Users can develop their own implementation of the MVC layer separation or use MvcTools. Controllers made with MvcTools are very portable : they feature their own Input and Output abstraction. Using ConsoleTools and the MvcTools, it's possible for controllers to be run from Console or through an HTTP request, but should not be limited to those I/O protocols. Note that this is extremely interresting for workflow controllers : more interfaces for more actors. Current Implementation == The template component is an excellent tool for making the View layer. The PersistentObject component is an excellent tool for making the Model layer. The PersistentObjectDatabaseSchemaTiein generators should be able to generate CRUD controllers, this is not implemented *as of now* but i'm working on that with the aggrement of Derick. Requirements - an MVC pattern viable with TDD/BDD, - controllers with I/O abstraction, - fully-featured MVC tools. Design goals The MVC pattern should be quiet simple but fully-featured unleashing the power of PHP in making modern applications. Routers One router per-protocol, transforming the user-request into an abstract request object. (ezcUrl is optionnal) Request The request object provides methods for the controller to check : - user input arguments, - user input data, - user input cookie. Controllers Controllers have a static method returning their ezcConsoleInput with all options, and a method to process the abstract request and return the abstract output object. OutputObjects OutputObject is an interface that should be implemented by output object classes, for example : a table, a dialog, a templateWrapper ... Output One Output-per-protocol. The Ouput should hold any number of OutputObjects, taking care of their processing, rendering and sending response. The Output should be selected by the router : the router should choose an asynchronous Output object for classic HTTP requests and a live Output object for CLI requests. Special Considerations == MvcTools should not supply deployment tools, another component should handle this. Diagrams Example implementation -- First stage : router - The router generates a Request object abstracting the HTTP request or the CLI command line. - The router generates an Output object, depending on the request protocol. - The router must select the controller object to use : - If the current Request object against the requested controller's options allows the controller to be run : return the controller. - If the current Request cannot run the controller : return the controllerthat will accept the provided Request - the controller that allows interfacing with the requested controller (help-text/form ...). Second stage : controller ezComponents provide many tools to implement in a controller process. The controller should process the Request object and generate an Output object, with optionnal abstracted Output elements (datatable, input form, template). It can write in the user's cookie (ie. ~/.cookie or HTTP COOKIE). Each Output object should accept other Output objects as Output element : allowing to use several sub-controllers per request. In the case of the HTTP Output, it would allow pluging-in a dynamic menu controller, the main Output should decide where to put it in it's view (new variable $dynamicMenu in it's template for example). Third stage : output Each Output class is independant and can render itself and is renderable as another Output's plug-in. Example development diagram --- Models, their tests, their CRUD controller and their tests are generated by PersistentObjectDatabaseSchemaTiein, there should not be much work. Develop controller's tests using the provided testRequestGenerator class allowing to craft requests, and the testOutputAsserter. Making it confortable to cover 100% of the code of the controller. Optionnaly develop additionnal Output objects. Developp a router
[Components] ezcInputFormDefinitionElement claims for it's independence
Hello everybody, In the context of the development of a component similar to PEAR::QuickForm : i though that UserInput form elements should be able to validate themselves. This would allow the QF-like elements to check if a valid input was sent in order to attribute itself the input value in it's constructor, without having to create a ezcInputForm for each validation. But anyway, this makes the design of UserInput more natural for me. I attached the patch, you might have to fix the paths though. Note that UserInput passes all tests when the patch is applied. Anyway, for the moment i'll use extensions in my project, i was just sharing my work for you to review. Good day and thanks for your support. UserInputElementDefinitionValidationIndependence.patch Description: Binary data -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
