Register to post in forums, or Log in to your existing account
 

This forum is locked: you cannot post, reply to, or edit topics.  This topic is locked: you cannot edit posts or make replies.     Home » Forums » General zApp Discussion
The Raven
Magician


Joined: 13 Oct 2000
Posts: 463

PostPosted: Thu Sep 09, 2004 12:00 am   

How to Customize Forms Properly?
 
When you have released zMail, and eMobius is out there in the public, I was thinking of how we will be customizing it in an extensible manner. Another post on this board, by Zugg if I recall, mentioned the bad way of customizing that requires you to edit original source files. This makes it hard to add more than one customization, and nearly impossible to do it automatically. He mentioned the 'quick reply' capability that was added to this board, that required editing files.

My concern is how we will be extending Zeus applications after they are 'published'. We need a way to extend them by ADDING files to an application's folders, without having to edit any of the files there. So, for example, if a Zeus application looked for a folder called 'myname.plugins', and loaded all the .zpl files in there...

Second, a plugin needs a place to insert itself into the interface. There are a few possibilities. Plugins could attach themselves to edges, like toolbars. They could be floating windows. Or they could override existing controls on the page. Best of course would be to allow all of these.

Overriding controls offers the most potential. You could override an Edit window, and supplant it with a panel that contains an edit window and some extra controls. When the Zeus application references the old control, the call is passed to the plugin object. This plugin, which has the same interface as the old control, would usually mostly proxy the functionality of the old control to the embedded copy of the old control, though it might intercept some behavior and modify it.

This kind of overriding would require Zeus to handle interface and scope issues natively... I don't know how hard that would be, but I'm sure it's not trivial. It would also require 'container' objects in Zeus that function like code blocks in other languages. These containers (perhaps like a 'panel' widget) would limit scope within them, and would offer a mutable interface to the rest of the application. Finally, it would create the need for 'this.' and 'parent.' type operators, that refer to the current object, and the parent of the current object.

I'm rambling off topic... I guess my main point is that I'd like to make sure that extending applications is possible without editing their ZML files. Providing fixed docking points to every window is one way... having plugins be floating windows that can access the same namespace is another... and allowing object overridig is a third. There may well be others. But it would be nice of a convenient extension mechanism was created to allow easy extension of Zeus apps.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Sep 09, 2004 1:34 am   
 
This isn't implemented yet, but my basic idea is that it will look for plugin files in a /plugin folder within the application folder. The INI file will be used to determine what plugins are enabled or disabled.

After reading the initial application ZML file, it will then read each of the plugin ZML files. Anything in the plugin ZML files that has the same name as an existing component will allow you to override properties of the existing object. Any items with new names will add new elements to the interface.

For example, if the original ZML file had:

Code:
<toolbar name='main'>
  <item name='FileMenu' caption='File'/>
</toolbar>


Then in your plugin ZML file you could do two things: 1) to override the FileMenu item you can do this:

Code:
<toolbar name='main'>
  <item name='FileMenu' caption='My Name'/>
</toolbar>


This would change the caption of the menu item. Or, 2) to add a new menu item you can do this:

Code:
<toolbar name='main'>
  <item name='NewItem' caption='New'/>
</toolbar>


Any item that doesn't have a name cannot be overridden by plugins. So you can control that. If more than one plugin modifies the same property of the same object, then the last plugin loaded "wins".

"Docking" gets more complicated. I haven't found a good docking system yet and I am *not* going to use the buggy Delphi code that I used in zMUD. So I'll have to wait until I find a good docking manager before I decide how this would work.

But, using the current alignment methods, you can easily add your own panels to the existing interface. For example, just declaring a new panel in your plugin with a unique name and setting it's alignment to "top" will ensure that it gets put at the top of the window after the existing controls that are aligned to the top.

I'll also provide a way to insert a new control after an existing control rather than always having the new control appear at the end. This will allow you to put a new menu item into the middle of an existing menu for example.

Now, another trick that I'll be implementing allows you to bypass the named item restriction to some extent. It's very common to have lots of unnamed Panels in the interface just to control alignment. So, each control has a "Parent" property that you can set. There are two ways to set it. Using Parent=ControlName will set the ControlName as the containing Parent of your new object without having to reproduce the entire hierarchy of all of the parent controls. You will also be able to use the property SameParent=ControlName to assign the Parent of your control to be the same as the parent of an existing named control. This would allow you to put your control within the same un-named panel as an existing control, for example.

All plugins have full access to the global namespace which means they can access any control in any window that is currently open. Since the <SCRIPT> tag allows you to mix scripting languages, you can also write the scripts in your plugin in whatever scripting language you choose rather than being constrained to use the same language as the main application.

Those are my current thoughts. I really want to make this system easy for dropping a plugin file into a directory and just having it work. The easier it is for plugins to work and the easier to install, the more they will get written and used.
Reply with quote
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Home » Forums » General zApp Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
© 2009 Zugg Software. Hosted on Wolfpaw.net