Widget structure changes

Hi,

Passing an array into the widget
I’ve been thinking that when a user enters something like [[Widget? &param=`One` &param=`Two` ]] the parser should store the values inside and array. This means that the variable $param will be an array containing the values ’One’ and ’Two’.

Handling parameters
Also the widgets should not extract the variables that where passed via the from the document. They should be stored inside an array called $parameters or better yet $this->parameters.

Object structure
Each widget can be seen as an object that contains events and custom methods. This means that you can reference the widget object using the $this variable. The following is an example of a widget:



Widgets will have a property called $isDesignMode (this is something that will be explained later) and along with the following event structure:

Widget Standard Events

OnInit
OnHandlePostBack
OnHandleAjaxRequest
OnHandleEvent - triggered from within a document
OnParse - this is only triggered if the widget is used on a page
OnFormatContent - triggered by content fields
OnBindContent - use by content @Binding fields

Widget System/Custom Events - supports priority

OnManagerLogin
OnWebLogin
OnOtherSystemEvents 
OnSMFLogin
OnSMFPost
OnOtherCustomEvents

What do you think?

Yes, yes, yes! These are all great ideas. I’ve been thinking that we need something like this for a while.

Here’s my one concern though: I want to be able to write multiple classes in a widget and not be limited to coding within a pre-defined widget class. Maybe I’m not understanding exactly how you want to accomplish this but if you’re using $this then I assume you want to wrap the whole widget inside of a class, which would mean that you’d be limited to defining one class in that widget, right (I don’t think you can write nested classes especially in PHP, can you? And if you can you still probably shouldn’t.)? So, instead of using $this and forcing everything inside a class I suggest we export something like a $this_widget or even $_this if you like, whatever. That should give us the greatest amount of flexibility to write multiple classes if need be and it should be fairly simple to extend the Widget class.

I’m no OO guru and I haven’t done all of my research on PHP4 OO vs PHP5 OO so I could be wrong about all of this but I’ll throw it out there anyway.

Ok, I can make it so that you can extend the base class of a widget. This will be similar to the way how CFOs (Content Field Objects) will work.

This means that you code will look like:

class WidgetName extends CustomBaseWidget {
// widget code here
}

where CustomBaseWidget must extend BaseWidget

Quote from: xwisdom at Dec 16, 2005, 04:49 PM

This means that you code will look like:

class WidgetName extends CustomBaseWidget {
// widget code here
}

Beautiful! This should give us a lot of flexibility. We should be able to easily create a widget "complier" specifically for legacy snippets and plugins and start using the new widget framework gradually.

FWIW, in my demo that will be available this weekend, every persistent object in the system will become a class like this, and can be auto-generated, simply by creating an xml definition of the database schema. In this way we can also auto-generate install/upgrade sql scripts. And there is built-in subclassing support, so you can simply identify subclasses via an extra column in the table, and have it handle Widgets and any subclasses of it in a single table. In the generated stub classes, we add our content management logic and API function implementations. We just need to figure out the specifics of migrating from one table structure/class definition to another when making major changes. I have an idea of how to manage that with Phing and the XML schema representing the data/object model. Imagine changing a class definition and having the appropriate install and upgrade SQL scripts for all supported DB platforms generated automatically at build time, along with API docs re-generated and uploaded to our web site... This is where I want to take this project; I’ve been there before, and it’s not as hard as it sounds. It just takes a dedication to laziness and good knowledge of OO patterns (as well as anti-patterns, as Victor reminded me ).

I’ve worked on many OO systems, including ones that used code generation techniques, run-time class generation, automated builds with unit-testing, Extreme programming techniques, etc. And this will make development of the core of MODx as easy as it is to develop sites with it once we all get the hang of it. Even better, it will attract real talent to our team that can only help make MODx even better.

This sounds wonderful. I can’t wait to learn from you all how to get my feeble mind around it all!

When creating a Widget you are not required to create a class object or file. There is no need for creating interfaces, abstracts, etc at all. More on this later.

If you don’t create an object of the Widget class, how do you work with the methods of it? I think you missed my point Raymond. I was talking about the persistence object in our framework representing the storage of Widgets.

Anyway. The initial Propel-generated, OO-powered MODx is merged into my branch. It works well on new installs, but again you must have PHP5/MySQL 4.1.x+. Lot’s of work to do to get it down to the performance level we currently have in trunk, but the integration was simple, and we have a very intuitive, and easy to use data layer that works across several database platforms. Now, time to optimize and remove unneeded junk.

Take a look if you’re curious. I’ll put together build and development environment instructions tomorrow and we can go from there. I’ll also be checking in the version of Propel we’ll be using, as I’ve customized some of the code to accomodate runtime definition of database names and prefixes, which still needs some refinement, but it works for now. More details soon..

IMPORTANT -- will not work on upgrades because I have yet to write the user merge update SQL, so...

Jason,

The object I’m refering have nothing to do with the database object.

I’ll have to get it working for all to see before I even attempt to explain how it will work.

So widgets will not be persisted in the database?