You are not logged in.
Pages: 1
There are two topics on plugin that I' like to discuss to have other developpers point of view:
1 - More and more plugins are dealing with server request (only PHP now..), then having all of them launched and ready at start which may cause long time to load if they need request at start.. I don't think that a good idea to have everything on start... Gogo does'nt like the approach to be able to load plugin onDemand.. I have no real idea but I think it should be a limitation in future... Opinions ?
2 - Following the discussion on several other threads passing structures from client to server and vice-versa seems to be in discussion and not clear... Just to be sure : why passing JS code (structure) and not data encoding (XML for example). I would prefer to manipulate a DOM structure for data than variables... Opinions ?
Offline
1.
For example the linker plugin: it is fully loaded (the html-code, the links-tree, everything) when starting the editor.
I don't know if you can allreay work with the editor while it is beeing loaded - if yes, its nice! if not.... why not load it when we need it?
(i'm sure there are other arguments too!)
2.
mho:
its easier passing JS-code that passing xml-code (which has to be parsed...)
...are there easy-to-use, fast javascript-xml-parsers? if so... we should take a look at them D:
Niko
Offline
1.
why not load it when we need it?
That's also my opinion...
By the way I don't have any idea of the performance if we used asynchronized threads.. Have you experimented it on browser?
2. I don't know this point well but DOM interface of browser cannot be used?
Offline
1. I don't like the idea of on-demand plugin loading. Plugins should be loaded once at runtime, BUT, the plugins themselves should be designed so that thier initialization can be done "in the background" or on demand.
2. Parsing XML is slow. eval(javascriptCodeHere) is fast. Whats the point of PHP -> XML -> Javascript instead of just PHP -> Javascript, there is no advantage gained by the XML adbstraction in this case.
James Sleeman
Offline
2. Parsing XML is slow. eval(javascriptCodeHere) is fast. Whats the point of PHP -> XML -> Javascript instead of just PHP -> Javascript, there is no advantage gained by the XML adbstraction in this case.
I absolutely agree.
-----------------------------------------------------------------------------------------
Content Management with Business Intelligence [url]http://www.formvista.com[/url]
Offline
Hi, i'm mokhet another xinha noob here, finally manage to make it works with my old php class. It's not that different of htmlarea to initialise, even simpler i would say. /thumbsup
1. I don't like the idea of on-demand plugin loading. Plugins should be loaded once at runtime, BUT, the plugins themselves should be designed so that thier initialization can be done "in the background" or on demand.
I totally agree with this point. If everything is preloaded, i think it's too much, something must be wrong in the plugin init. Not the fault of plugin organisation but more the fault of way plugin was made. Didnt looked very close to the plugins (especially panels one) yet, but there must be some way to have a preload default page with a pretty text and then load the content when icon is clicked at the same time the panel is shown.
by the way, talking about plugins, as i said i didnt looked very close to them yet, but i will have to because i have a few made for htmlarea. Are there any real important changement or other stuff to know about plugins since htmlarea cvs 0.95 i should know or read ? thank
Offline
The need for a plugin dev doc seems to become more and more urgent. Before that, perhaps it could be a good time to discuss some architectural points.
I think that we should follow the gogo point of view (all plugin must be "loaded" at start) but then all plugins must respect an interface with methods to "control" the loading and like mokhet said control also errors (I really don't appreciate to see my xinha going down just because of a stupid error: missing an french translation in resource...)
Another point is that some plugins need other plugins.. We should perhaps bescribe more how strong is the dependencies..
Offline
by the way, talking about plugins, as i said i didnt looked very close to them yet, but i will have to because i have a few made for htmlarea. Are there any real important changement or other stuff to know about plugins since htmlarea cvs 0.95 i should know or read ? thank
Plugins should more or less just drop in, the only changes that might be required are if you do anything with the editor "in the raw" (that is specifically manipulating the iframe and such).
Another point is that some plugins need other plugins.. We should perhaps bescribe more how strong is the dependencies..
I think it shuld be possible for plugins to load other plugins as it is.
James Sleeman
Offline
Pages: 1