Going to explain how I plan to do this hoping for comments. Again, if someone else with more experience is willing to take on such a project I am quite willing to go work on something else but otherwise here is my plan...

First off I am going to do what I can to document the "working" frameworks I can get my hands on that work with xoops today. (One example is smart objects. ) I will attempt to look at a couple other ones and document those as well to the best of my abilities. This is to get a feel for how they are done as well as look at the functions etc.

At the moment I am looking at using Doxygen as a utility to help document these. Mostly because it is the utility used to create the Core API documentation. (Thanks Mamba for the link)

After I document things I will try to split the items into like resources unless they already are. (Such as DB classes and function, GD, Etc...) Then I will create a more universal framework based directly on the frameworks I have. This is the step I will look for reusable code and such between frameworks and utilize this. I will not consider the quality of code at this point, I will just basically copy and paste. I will ONLY include code that appears to be generic and universally usable while ignoring specific code for limited functionality. When more then one framework has the same functions I will try to use my best guess as to which one has the better coding and use it while attempting to maintain the function for all the affected frameworks.

Once this last step is complete my next intention is to include "plugins" to allow this framework to directly replace the original works. These plugins will contain aliasing to point the old functions to the new ones. They will also include any code that wasn't included in the generic framework for whatever reason. (On my initial inspection of the smart objects module it wasn't JUST a framework but added additional stuff which wouldn't be included in the generic framework but would be necessary to include in some form to allow the generic framework to replace the original work in full.)

Once this is all done and tested to make sure it works as advertised then the next thing to do is go through the code and look for ways to use core code or improve the coding whenever it is possible.

It is my intention to also document all of this as much as I can so that a new module developer can just come along and use the framework as is and not wonder how the functions work. And as the code is improved and the framework is upgraded the modules based on it should just work fine.

I will likely continue the document, convert code, code improve steps with other frameworks as I go on until I get through most of them that are out there publicly. Once I am comfortable with this I may then look at coding for other CMS's or similar projects and see if there are any other routines that could be included. My intention is to use this framework for my own works as well as for modules that I "move to blue". If I find any more useful code that sounds like it would be good to include I will do my best to include it as well.

I plan to use the existing frameworks as I expect them to be reasonably well written, and point out things missing from the core that will make module writing easier. Not to mention give me a HUGE head start on developing this and not having to go from scratch. I do understand that different programmers have different styles and when I go to the code improvement stage I may decide to do the same function totally different for clarity, performance, or compatibility reasons.

I have listed this plan as I hope if I am missing something or if someone has a suggestion they can offer it up. This is a learning experience for me and I definitely need feedback.

And if you think I am a total idiot, feel free to PM me about it. But I DO hope if that is your view that you can at least offer some guidance and explanation why you feel that way.

(Following was added after the original message...)
Also, almost forgot, I will be developing this for 2.4.5+ although the original works may have worked in 2.3.3 or 2.0.18 etc... If compatibility can be maintained with the older versions I will do my best to do so.

As new technologies are added to xoops I will try to add to the framework as well. Items Such as jquery come to mind and the work Simon has done with the new database access structure. (As long as this can work along side the original database access stuff I will likely add this as a prelude to it becoming core. And this will allow modules to use that code with 2.4.5 and 3.0 even if it is not used in core until 3.0)

To support the different cores there may be "core plugins" as well with the intent to maintain module compatibility through different versions of xoops unless this is deemed unnecessary. This may be a way to also allow new functionality included in 2.5+ to be included in modules while maintaining compatibility with 2.4.5. (sort of a stop gap between versions.)

Due to the complexity of this I expect to make this a module so calling it a framework might not be totally accurate. That will allow an admin preference to be added to allow some selectable preferences unless a better option is available. (plugins such as the smartobjects and such will be selectable options so you don't have to use them if you don't have a use for them.)

As to a name, should this be called Xoops Module Framework? I was also thinking Xoops Module Objects.

Rodney

Quote:
Yes, based on your previous post that's how I interpreted it. If that's not what you meant, I apologize. However, I would like to know who/what you meant by "leaching code without attribution"

Quote:
Good! I appreciate it very much!

Quote:
We do listen to everybody very carefully, trying to find a balanced approach that is the best for XOOPS overall long-term success. Sometimes it works and everybody is happy, sometime some parties are not happy. And we have to accept that sometimes we need to respectfully agree to disagree, and move on.

People come and leave for various reasons. My understanding was that Skalpa left because of health reasons, but maybe you know more than the official reasons published here on XOOPS.

You've mentioned also Onokazu. We were very happy to see that Onokazu, the founder of XOOPS, agreed to come back two years ago and join our Advisory Board, and continues to contribute code and ideas to XOOPS, showing that he doesn't consider us as somebody who wouldn't listen to him

Steve, if you want to discuss it further, send me PM, but as requested here before, let's keep this thread focused on the Frameworks and nothing else.

Very cool, Rodney! I am definitely looking forward to the results of your work.

As you work on the Framework, please consider how to make it easier for developers to create D3 modules (see the message I posted almost a year ago). Unless we believe that D3 approach to module development (especially the security part), is too old, and we should use something else.

Quote:

Will look into that as well.

You will note I added a little more to the last post I made.. Didn't think it warranted a new message as it should have been in that message in the first place.

I would like to add that modules should have all their functions documented in the code to make things easier in the long run. They should be setup so that a php documentation program such as doxygen can easily make a reference guide and make it easier for others to upgrade and modify the code later. Not to mention it is just good practice. All of my programming classes have emphasized how important documentation is. Not just for other people but also that when the original author goes back a year later they can easily pick up where they left off.

It would also be nice if people could include a description for what each database entry is for when they build a module. I don't know if the .sql file supports commenting but if it doesn't then there should be a comment file somewhere describing them in a universal format. (Maybe like a standard language file called "database" with just a list of the database entry and a short description beside it.)

But this might be getting out of the topic of this thread again... ;)

Also, what ever happened to the XAM framework? Sounds alot like what I would like to accomplish but I have never heard of it before.

Quote:
Yes, that should be a requirement.

I'm all for good documentation. See the example of a perfectly released module...

Quote:I don't think that was what Steve meant. He was only reacting on redheadedrod who wrote:
Quote:This is a view where open source is a bazaar, where you can pick up everything you want for free, and for the ease of things simply forget of copyrights and attributing to it.
A quite rightly concern of skenow!
I don't mean by this that redheadedrod meant it that way, but for the careless reader, the danger of interpreting it that way is certainly there!

All other things that one would carry on, like making general remarks personal to himself or others (what is mostimes worse) has nothing to do with this discussion.
If you cannot attribute something positive or in an unpersonal way, then be silent, else we go again in the childish did not, did too of years ago.

The discussion here is what about the Frameworks!

What does XOOPS need?
How do we define and where do we draw (or do we need) the lines between core, Frameworks, modules.
What do we have?
How do they differ or have similarities?
What do we keep?

Problem with XOOPS is that there is no (real) API, that explains every core or Framework variable (use and abuse) and function with input, output, processing done, limitations, generated errors, example code, ...) and so stimulates the reuse of existing functions.
On the other hand module developers don't get enough of their concerns (= unimplemented functions) realised as new features in the core or Frameworks.

Stuff enough to discuss!

I hope everybody can be again right on track now or I will come with my moderators' axe.

I returned after a few months break. Maybe I missed some discussion, but let me throw in there some opinions.

First. What exactly the functionality we expect from a module framework? What classes should include, feature lists, etc..

Personally (I have some experience in develop XOOPS modules), I do not see a huge need for additional layers as the module framework. Perhaps the collection classes and helpers, yes. But whether we call this framework?
Many developers have their own ideas and habits and can not meet all of one 'universal' framework.
In my vision, the core defines modules routine (how mods interact with each other, with layers of data, logic, presentation) and provide the bricks (such as XoopsObjects) to build these modules.
So... I think more useful is good documentation and tutorials how to build the modern XOOPS modules, how to properly use XoopsObject, etc. Unfortunately, my knowledge in this area is quite limited to help into docs.

Quote:

Well, everything depends on how the core is designed as a modular and if we stick rigidly MVC or MVP... but I do not have much experience, so I can not judge.

I am mulling over how far I should extend things and wanted to reiterate what I am looking to accomplish with this...

Initially I am looking to duplicate the function of multiple frameworks in one framework/module. The intension is to bring a generic Library of functions to developers to help build modules quicker. The hope is that I will be able to build a good utility with this and with help from more knowledgable programmers bring this to fruitation and hopefully include some version of this with a future version of xoops but in the mean time be able to include it with current versions as an add on. This all has been discussed previously in this thread.

Since I am planning to base this off frameworks already in existance I plan to have plugins to allow this more generic one to replace those other available ones.

I am also considering (If even possible) to include "compatibility" add ins. There would be two types.
One would allow older modules to work with newer xoops and php. These ones would include coding that if you turn on "debug" that depreciated functions would come up as warnings and suggested functions to replace them where possible.
The other type would allow newer modules to work with older versions of Xoops.

At this point in time the compatibility add ins are just a consideration. Obviously since there is no code in place there is much to do. Just wanted to share ideas and see if I am missing something.

Quote:

You want to provide adapters/proxies so module developers could use same API they have in their Frameworks?

Let's say developer has this function:
moduleframework::getConfig()

and you create a plugin that developer can use like
plugin::getConfig()

mapping to the Generic Framework:
generic::getModuleConfig()

?

Seems to much work to solve a not existing problem. The idea is to push developers to use the generic Framework API.

Yes that is the plan Trabis,

ONLY reason for ANY thought of any of the plugins or addins would be to allow already existing modules to use the generic framework without having to modify them while the "Move to blue" is progressing.

The documentation included would briefly mention the purpose of the plugins but would only document the main framework its self.

The intention of the xoops version based addins is again to allow modules to work with other versions that don't now. (These will be setup to allow a developer to turn on the debug and have it point out the offending functions and such so they can be upgraded to work with the newer versions of xoops.)

Guessing once this framework is done to a point it can be included in the core that the blue move should have helped move the majority of modules to not need any of those add ons. Not planning on spending a lot of time on them.

Once I get into it I might find it easier to modify the original programs that depended on those frameworks then to include the plugins. No sense in creating them if there are only 4 or 5 programs based on them.

I appreciate your input Trabis as well as anyone else that can add their thoughts.