We're only about a year away from starting WebGUI 8 development. As such I thought it might be a good idea to start a new series on The Black Blog about it. None of this is set in stone mind you, it's just my thought on where things should be headed.
In this first installment, I'd like to talk about Asset definitions. For you code monkeys specifically the definition() method and everything that goes with it like getEditForm(), update(), etc. For the rest of you, I'm talking about automation. Through the definition of the asset, the asset knows what properties it has and how to use them. This allows us to be able to automatically generate edit forms, display certain data, import/export packages, create prototypes, override fields in shortcuts, and a whole host of other things.
The problem is that not all assets use definitions. Some assets manually generate forms and don't fully fill out their properties in the definition. That's because a long time ago, during 6.x we didn't do all the automation that we do today.
So in WebGUI 8 I think that we'll eliminate these vestigial elements of the asset system, and require all assets to fully fill out their definition. By doing this we'll be able to have an admin edit form for things like Wiki Pages and Collaboration System Posts, where we can adjust settings other than those exposed through the template.
We'll be able to automatically expose web services from all assets so that they can be updated and extracted from remotely. That sort of functionality will mean that templates can be directly edited in Dreamweaver and when you hit save they're published to the site, and photos can be uploaded directly from your hard drive without using a web form, among other things.
It will allow us to do even cooler things with packages, like synchronizing assets across multiple web sites. So The Black Blog could, for example, be published here on plainblack.com, as well as webgui.nl (the Dutch language WebGUI site), and in your corporate intranet, and when someone makes a post to one of them, it gets published to all of them.
There is a downside to this however. It will mean that some custom built assets will break, and thusly there will be an API change. That's ok, in that we do break API's at major release points, but it will mean extra work for people who have built their own assets that don't fully use the definition. For the greater good of the community, I think this is an acceptable burden. And if the assets were written correctly in the first place, then those developers will have nothing to worry about.
"It will allow us to do even cooler things with packages, like synchronizing assets across multiple web sites. So The Black Blog could, for example, be published here on plainblack.com, as well as webgui.nl (the Dutch language WebGUI site), and in your corporate intranet, and when someone makes a post to one of them, it gets published to all of them."
This to me is heaven. But if this can be done, this will sync the content, will it also sync the associated template, this will defeat many uses, since I want to publish your blog for examaple on my site template.
Quote: An eye for an Eye only helps make the whole world blind
You have to understand, this just gives us the ability to enable something like that. I'm not saying that the actual feature will be released in WebGUI 8. It just becomes an option. That's why going down this path is so attractive, it opens a lot of options.
One of the things you can't do in the definition now, I believe, is only show a certain form element if you are editing an asset and not if you adding it. That's why now in the getEditForm function you add those fields to the tabbed form like so for example:
) if $self->session->form->process("func") ne 'add';
Sometimes you need people to define additional data before they save an asset when it's first added. The get one ore more additional steps if they add the asset, by using the whatNext option. This information may be made editable later in the same way as the code snippet above.
Will the new definition add properties to make this possible? Things like the snippet above will not be compatible or will they?
Internet for the public sector
Date: 5/8/2008 4:21 pm
I hadn't considered that. Good ideas.