[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [jfw] General configurations



Annotations are definitely one solution, but until they become a core PHP solution using them is going to be clunky (I integrated Doctrine ORM with Annotations support into a Framework based project, getting the configuration right for that was rather interesting).

Having events scattered throughout the system would definitely be a +1 from me.  It's something we're really missing right now, you have to override anything to add any sort of event/hook based system into an application; it should be something we aim to support in the API.

I'm having a hard time putting to words what's in my mind right now, but I think we really should start experimenting with code and getting a feel for where we want parts of the API to go.  In the case of the Form package, I'd almost suggest just starting fresh with it, splitting it into logical components.  There's a validation piece, rendering piece, and the primary API minimum; that API should be hookable in some form (events presumably being one of the easier ways to get started with that).  We can dispatch events with ease, but registering event listeners is something that's a little tricky right now.  So how can we make it a bit easier to add event listeners into a dispatcher?  Symfony lets you do it through either the DI Container (which gets compiled and cached) or using event subscribers.  The public API only supports simple arrays for the data store, how can we make that work with perhaps our DataObject or other types of objects?  I think the Form package can become a model of a well architected API and experimenting with it would be rather interesting.

On Mon, Mar 2, 2015 at 10:55 AM, Nils Rückmann <mail AT nueckman.de> wrote:
Hi Michael, thanks for your response. Registry is a great package and should definitely get more attention as primary tool for hierarchical key/value or configuration storage. But it's only for basic configurations. It's not possible, at least not in a convenient way, to define the behavior of an object. To define some sort of behavior most other frameworks are using annotations, but (and please mind that this is only an opinion) using annotations seems not good enough for me. PHP is an interpreted language and should not be forced to be compiled.

Let's take forms as example (because its so convenient): Today we just use some sort of meta data to create a form, the format doesn't matter as its always "external" data. Using external meta data provides a simple solution to define fields in a more or less restricted way. But what if we see a form not just as a collection of field but as a real and active object. A form contains more than simple field definition. Hence, even fields are not that simple. each field is an object which behavior may vary. 

The easiest solution would be to use some sort of hooks/events or even AOP, but those solutions have one downside in common: They separating thing. Most of the time this is exactly what we want, but sometimes it might be better to have atomic element which can be shared, transfered and versioned.

A plastic example:
Most applications will have a graphic user interface where they manage persistent data (like articles, categories, etc.). If we see a form as an atomic element, there could be a versioned basic form with required fields, some behavioral information like which action to call or additional actions, and more. Not only that it could be extended by other forms, but also be forked to fit in another context. We were not forced to write the same code (create meta data, create form, create the markup, create logic like validations or other actions) all over again.
Imagine their would be a class "MyAppItemForm" which has all informations it needs for doing its job. It's extactly what some frameworks are doing with annotations. They write annotations and generate a "real class" which will be cached. But as i mentioned: Annotations doesn't seem right to me.

I don't know how else i could describe it. And of course i don't have a solution, that's the reason i thought it might be something where we can share our minds.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.