Plugins module #512
Comments
|
I've started to write this several times, and I keep getting interrupted. A plugin manager sounds like a great idea. First, a warning ;)One of the first things on my list of things to do is to revamp the way modules are defined. We have way too much stuff defined in global space, and that gets in the way of growth. All the building function names with a dirname makes things ugly and awkward. PHP has classes which are great to keep things out of global space. We also have namespaces to keep class names from colliding. Applying these to modules would give us a lot of strength. Each module gets a defined namespace. Routine pieces of code will become routine classes. Now we load the file specified in $modversion['onInstall'] and call the 'xoops_module_update_' . $dirname function. Instead we would use the module's namespace and check for a $namespace/System/Update class, and invoke the update() method. Instead of the current block schemes, each block becomes a class, $namespace/Blocks/$classname, that includes all of the block's pieces. All of these classes would have defined interfaces. We end up with reusable and testable code. All of the interaction with these interfaces would get wrapped up as module environment layer, an object that all the module interactions go through. That environment would be passed in to the module code as it is run so we no longer have to depend on globals. You could work with multiple modules in the same transaction, opening up lots of new techniques. I see a lot of benefits from this approach. That change is in the very near future. Now, if I have not scared you off, here are some thoughts on plugins.One of my main concerns is configuration. I loath the "copy this file here, edit this odd piece here" approach. It complicates updates, as you have to track what you can or can't overwrite. Even if you can keep track of that, you have to look for changes you might need to merge in. It isn't friendly, and it isn't acceptable. One of the goals with the service manager, for example, was just install it, and it is ready to use. There is a similar concept in the text sanitizer now. Each extension has its own default configuration information. This is collected from each extension, and then merged with saved configuration for all the extensions. That saved configuration is in YAML, and saved in data/configs. The extension configuration starts from a scan of the classes in the directory, but it also triggers an event allowing additional extensions to be supplied by modules. The configuration is created when it doesn't exist. It is safe from overwrites. It can be easily edited. It can be created in advance and copied in during an install to create the desired setup as a configuration item. And it is ready to use right away. OK, it still should have a nice GUI config tool :( But, otherwise, it a good example of how I think things should work. It is an example of the level I want us to achieve. Please, ask questions, make suggestions. I just want us to be on the same page. Sorry for the length. |
|
I 100% agree with avoiding the global scope and have classes implementing
interfaces, etc.
Has for plugins, they do not require configuration. Regarding the move to
namespaces, we will probably need to change the file named
plugins/interface.php to something else. Interface is a reserved name.
The module is almost finished, I will propose it soon.
Thanks.
Em 28/02/2017 17:02, "Richard Griffith" <[email protected]> escreveu:
… I've started to write this several times, and I keep getting interrupted.
A plugin manager sounds like a great idea.
First, a warning ;)
One of the first things on my list of things to do is to revamp the way
modules are defined. We have way too much stuff defined in global space,
and that gets in the way of growth. All the building function names with a
dirname makes things ugly and awkward. PHP has classes which are great to
keep things out of global space. We also have namespaces to keep class
names from colliding.
Applying these to modules would give us a lot of strength. Each module
gets a defined namespace. Routine pieces of code will become routine
classes.
Now we load the file specified in $modversion['onInstall'] and call the
'xoops_module_update_' . $dirname function. Instead we would use the
module's namespace and check for a $namespace/System/Update class, and
invoke the update() method.
Instead of the current block schemes, each block becomes a class,
$namespace/Blocks/$classname, that includes all of the block's pieces.
All of these classes would have defined interfaces. We end up with
reusable and testable code. All of the interaction with these interfaces
would get wrapped up as module environment layer, an object that all the
module interactions go through. That environment would be passed in to the
module code as it is run so we no longer have to depend on globals. You
could work with multiple modules in the same transaction, opening up lots
of new techniques.
I see a lot of benefits from this approach. That change is in the very
near future.
Now, if I have not scared you off, here are some thoughts on plugins.
One of my main concerns is configuration. I loath the "copy this file
here, edit this odd piece here" approach. It complicates updates, as you
have to track what you can or can't overwrite. Even if you can keep track
of that, you have to look for changes you might need to merge in. It isn't
friendly, and it isn't acceptable.
One of the goals with the service manager, for example, was just install
it, and it is ready to use. There is a similar concept in the text
sanitizer now. Each extension has its own default configuration
information. This is collected from each extension, and then merged with
saved configuration for all the extensions. That saved configuration is in
YAML, and saved in data/configs.
The extension configuration starts from a scan of the classes in the
directory, but it also triggers an event allowing additional extensions to
be supplied by modules.
The configuration is created when it doesn't exist. It is safe from
overwrites. It can be easily edited. It can be created in advance and
copied in during an install to create the desired setup as a configuration
item. And it is ready to use right away.
OK, it still should have a nice GUI config tool :( But, otherwise, it a
good example of how I think things should work. It is an example of the
level I want us to achieve.
Please, ask questions, make suggestions. I just want us to be on the same
page.
Sorry for the length.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#512 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGFR79y3V3Ml94etkpdgLddlGtq1k0BMks5rhFMEgaJpZM4MNwiG>
.
|
|
I would like to know what features of system module should be exported to
other modules.
I am currently working on a 'waiting' module. What should I do next?
I was thinking in making a usermenu module and a mainmenu module. This ones
only provide one block each.
The current system user block would still be installed by default but I
would remove plugins support from in.
I would probably drop system maimenu from install because having user block
is enough for admin to navigate to admin area and install the mainmenu if
needed.
Ideas?
Em 01/03/2017 14:21, "Luso Poemas" <[email protected]> escreveu:
… I 100% agree with avoiding the global scope and have classes implementing
interfaces, etc.
Has for plugins, they do not require configuration. Regarding the move to
namespaces, we will probably need to change the file named
plugins/interface.php to something else. Interface is a reserved name.
The module is almost finished, I will propose it soon.
Thanks.
Em 28/02/2017 17:02, "Richard Griffith" ***@***.***>
escreveu:
> I've started to write this several times, and I keep getting interrupted.
>
> A plugin manager sounds like a great idea.
> First, a warning ;)
>
> One of the first things on my list of things to do is to revamp the way
> modules are defined. We have way too much stuff defined in global space,
> and that gets in the way of growth. All the building function names with a
> dirname makes things ugly and awkward. PHP has classes which are great to
> keep things out of global space. We also have namespaces to keep class
> names from colliding.
>
> Applying these to modules would give us a lot of strength. Each module
> gets a defined namespace. Routine pieces of code will become routine
> classes.
>
> Now we load the file specified in $modversion['onInstall'] and call the
> 'xoops_module_update_' . $dirname function. Instead we would use the
> module's namespace and check for a $namespace/System/Update class, and
> invoke the update() method.
>
> Instead of the current block schemes, each block becomes a class,
> $namespace/Blocks/$classname, that includes all of the block's pieces.
>
> All of these classes would have defined interfaces. We end up with
> reusable and testable code. All of the interaction with these interfaces
> would get wrapped up as module environment layer, an object that all the
> module interactions go through. That environment would be passed in to the
> module code as it is run so we no longer have to depend on globals. You
> could work with multiple modules in the same transaction, opening up lots
> of new techniques.
>
> I see a lot of benefits from this approach. That change is in the very
> near future.
> Now, if I have not scared you off, here are some thoughts on plugins.
>
> One of my main concerns is configuration. I loath the "copy this file
> here, edit this odd piece here" approach. It complicates updates, as you
> have to track what you can or can't overwrite. Even if you can keep track
> of that, you have to look for changes you might need to merge in. It isn't
> friendly, and it isn't acceptable.
>
> One of the goals with the service manager, for example, was just install
> it, and it is ready to use. There is a similar concept in the text
> sanitizer now. Each extension has its own default configuration
> information. This is collected from each extension, and then merged with
> saved configuration for all the extensions. That saved configuration is in
> YAML, and saved in data/configs.
>
> The extension configuration starts from a scan of the classes in the
> directory, but it also triggers an event allowing additional extensions to
> be supplied by modules.
>
> The configuration is created when it doesn't exist. It is safe from
> overwrites. It can be easily edited. It can be created in advance and
> copied in during an install to create the desired setup as a configuration
> item. And it is ready to use right away.
>
> OK, it still should have a nice GUI config tool :( But, otherwise, it a
> good example of how I think things should work. It is an example of the
> level I want us to achieve.
>
> Please, ask questions, make suggestions. I just want us to be on the same
> page.
>
> Sorry for the length.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#512 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGFR79y3V3Ml94etkpdgLddlGtq1k0BMks5rhFMEgaJpZM4MNwiG>
> .
>
|
|
As per usual, here are a few thoughts ;) Waitings sounds good. Need the rss/backend, too. I do kind of like the userconfigs plugging in to the user menu. Makes much more sense that way than as a menu item. Not sure I want that to go away. I can imagine other possible use cases. Menus! We need improved menus. I know we have the menus module. My issue with it is that it tries to cover too many layers. I hope to push all the presentation responsibility to the theme. A theme could choose to use the menus mod rendering, but it shouldn't be the only way. I'd like to see some standard objects used to specify menu items and collections of menu items. I was sketching ideas in htdocs/xoops_lib/Xoops/Html/Menu -- been a while, feel free to adapt, replace or ignore. Current thinking for item properties is something like caption, link, icon class, image and tooltip text. Maybe that should be in a broader Attributes implementation (like forms) that could handle things like onclick? Things like the system and main menu plugins should communicate with the standard menu objects. I'd like to see menu definitions that could be expressed in multiple ways - block, nav bar section, etc. and chained together in different ways. For example, a menu could be a sub menu in another menu. With a good definition for the items, you could present them in many contexts A way to persist a named menu is a must, but it should be possible to join that seamlessly with dynamic menus. The current approach of editing the theme to modify the navbar menus needs to change. There is a real opportunity there. I'm sure you can work wonders. |
|
I proposed making a module for holding the usermenu block, so the plugins
would work with this module instead of the system module.
I think Xoops/Html/Menu should be implemented as a Form Element, actually,
we should rename Form Elements to Html Elements because they do not need to
be inside a form. The Form Element is a container, just like tabstray, and
you could easily add a breadcrumb or menu container. Links would be simple
Elements that could be rendered by themselves or inside containers.
An aside, look at this awsome class for building html elements:
https://github.com/naomik/htmlgen
I think the above class, and even XoopsForm, could be very helpful for
designers and it is a shame that smarty gets on the way.
Perhaps we should consider moving to php templates?
The menus module can generate navbars, breadcrumbs, etc but it takes some
extra steps to implement them in the theme (I have a bootstrap plugin for
it somewhere). Yes, once we have this new Html Elements, the menu module
can use them instead of providing it's own templates. The menu module seems
pretty broken, needs some refactoring.
2017-03-10 19:35 GMT+00:00 Richard Griffith <[email protected]>:
… As per usual, here are a few thoughts ;)
Waitings sounds good. Need the rss/backend, too.
I do kind of like the userconfigs plugging in to the user menu. Makes much
more sense that way than as a menu item. Not sure I want that to go away. I
can imagine other possible use cases.
Menus! We need improved menus.
I know we have the menus module. My issue with it is that it tries to
cover too many layers. I hope to push all the presentation responsibility
to the theme. A theme could choose to use the menus mod rendering, but it
shouldn't be the only way.
I'd like to see some standard objects used to specify menu items and
collections of menu items. I was sketching ideas in
htdocs/xoops_lib/Xoops/Html/Menu -- been a while, feel free to adapt,
replace or ignore. Current thinking for item properties is something like
caption, link, icon class, image and tooltip text. Maybe that should be in
a broader Attributes implementation (like forms) that could handle things
like onclick?
Things like the system and main menu plugins should communicate with the
standard menu objects.
I'd like to see menu definitions that could be expressed in multiple ways
- block, nav bar section, etc. and chained together in different ways. For
example, a menu could be a sub menu in another menu. With a good definition
for the items, you could present them in many contexts
A way to persist a named menu is a must, but it should be possible to join
that seamlessly with dynamic menus.
The current approach of editing the theme to modify the navbar menus needs
to change. There is a real opportunity there.
I'm sure you can work wonders.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#512 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGFR75mrMAK3Il-kGVl5FlF9e_2BQaWXks5rkaXogaJpZM4MNwiG>
.
|
I'm in complete agreement there. Sorry if there was confusion. The form and html classes are already siblings. Both come from Attributes. Forms need some extra attention because they really need to be a two way interaction. For example, I've been considering a form enhancement (tentatively called form spec.) This would replace the old token/NONCE idea for a more defensive posture using a broader specification for the whole form. As the form is built, each field would be added to a list of what to expect as input. That would accompany the form in a hidden field as a jwt. It would be signed, know what action the form was supposed to be submitted to, and what fields should be included in the post. On the way back, instead of just checking the token, we could verify we were looking at something we sent out, that it came back to the right place, and only the fields that were supposed to be in it are processed. We could wrap the incoming data into a Request object, so the program could access the data which would match the spec all or nothing. Should make it much easier for a module to just do the right thing, every time. I'll give naomik/htmlgen a look, but I'm not sure about dumping Smarty, just yet. You and Eduardo seem to agree on that, though :) Lots to think about. |
|
Smarty: we could open up XOOPS for other template engines, or pure phtml, and make XOOPS more agnostic about it. Of course, Smarty could remain as the default engine, but if somebody wants to use something else, no big deal. |
I'm thinking on building a plugins module to manage, well, modules plugins. The current system works fine but we cannot disable plugins without removing the files and we cannot set the execution order. For example, would be nice to reorder the user menu, add/remove user avatar, etc. Anybody working on this? What are your thoughts?
The text was updated successfully, but these errors were encountered: