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

Re: [jfw] General configurations



I'd have to dig through the platform pulls to find the notes on the DataObject class.  But in theory, you could combine the Registry and DataObject storage attributes and use what's left in Registry after that as a handler of sorts.

On Monday, March 2, 2015, Nils Rückmann <mail AT nueckman.de> wrote:
Well, i think an AOP-like approach is the key. Unfortunately there is currently no way to solve it without code generation. But i like the idea of a fresh start for the form package. Just tell me how you want to manage it (working group? repository playground?) and you can count me in.

Due to lack of documented purpose for the Registry package, i'm not so sure about the Data package and its symbiosis with Registry. Do we really need two packages ? Would it not be smarter if we have one DataObject/Registry which can hold hierarchical data (get, set, find, etc.) and some sort of DataHandler which can read/write arrays, objects, xml, json or whatever ?

Am Dienstag, 3. März 2015 02:12:52 UTC+1 schrieb Michael Babker:
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.

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


--
- Michael

Please pardon any errors, this message was sent from my iPhone.

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