Wednesday 14 September 2011 - http://projects.ez.no/ezblueprints
A collection of extensions, each one intended to demo an aspect of the eZ Publish API
Friday 16 September 2011 11:35:03 am
Excellent initiative Gaetano, much useful to beginners (and ex-beginners too, given the diversity of extension points on eZ Publish !).
Question :
is the intent to write stubs only, with no business logic inside it, or to add a basic, illustrating functionality within the stub ?
Cheers,
Friday 16 September 2011 2:05:02 pm
My take:
- naming of extensions: ezblueprintsxxx
- in every extension: extension.xml file, readme file with step by step instructions on creating the different files needed
- name different things different, eg. a view and its associated access function
- use or at least document using code comments every possible feature (eg. access functions with limitations, all params in module.php, etc...)
- not a lot of business logic in each extension, to keep user focused, but still a little bit, or extensions will make no sense
- I propose to use as common case for template operators and views some functionality related to filesystem manipulation:
. fetch function to get list of files in a directory (params, limit, offset, sort_by)
. tpl operators to get filemtime given filename (no params), filesize given filename (one param: output format)
. views that list all files in a given dir (without using fetch function)
Tuesday 20 September 2011 8:35:03 am
I also lean towards having a basic functionality to illustrate the type of extension. It is key to usefulness.
The name of the extension will be, for a template operator :
<code>ezblueprintstemplateoperator</code>
correct ?
Could that not be simplified down to templateoperator ?
Cheers,
Thursday 15 September 2011 1:35:03 am
Friday 16 September 2011 11:35:04 am