11
Mamba
Re: "Universal" module framework...
  • 2010/8/5 0:00

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Quote:
Developers keep asking (for years) what they can do for xoops, but unfortunately they are kept out of the core bussines. For reasons I still cannot understand.

Nobody is kept out, if they can deliver on what they promise and have the required set of skills.

In the last two years we have several people who wanted to contribute to the Core. Some of them did a very good job, some of them less.

Best two examples:

1) We have Trabis who was the main coordinator for 2.4.x series.

2) When Nicolas (ForMuss) came and said that he and couple of friends want to make System and Admin GUI more AJAX-based, they got the commission to go ahead with 2.5.0. And they did a very good job with that.

And now both Trabis and Nicolas agreed to focus on 2.5.0.

But we also had negative experiences with people contributing to the core, where the quality was not there, and later the core had to be cleaned up (as DJ had to do with 2.4.5). Which showed again that being a module developer, even a skilled one, doesn't make you necessarily a good Core developer. The same way as the best bricklayer or the best interior designer won't necessarily be good in house architecture. It just takes different set of skills.

So let's be fair here - nobody is being kept out of Core development, as long as they can deliver quality code.

Quote:
To be honest, the recent news release XOOPS Core Development Updates As Of August 1st, 2010 doesn't change much of this core (read X3) development problem. The basic structure, one man, stays the same, which is to my opinion a real pitty.

If you read it carefully, this was only the first phase. There are already other people involved as the Internal Review Team. And once the code is ready for a public Alpha, everybody will have a chance to contribute ideas and code.

It will be the same as with 2.4.x and 2.5.0 - people who want to contribute and have the right set of skills, will be more than welcome to do so.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

12
redheadedrod
Re: "Universal" module framework...

skenow wrote...
Quote:


Quote:

trabis wrote:
It is heavily based on smartobject and IPF.



'heavily based' doesn't even come close to describing the origin of the code.


Well you have to start somewhere. And why reinvent the wheel. This is one of the beauties of open source code...

To get a starting point I don't see an issue with using other peoples code. And actually as I have already said i would be looking at taking more then one of these developer frameworks and combining them into one. With the intention that you can hopefully just use the one framework with all of the supported pieces. Not to mention that the other developers have already worked these out for a reason.

But that is one of the purposes of this thread to discuss the starting point.

Doesn't necessarily mean the end product will be just a repackaging of something such as smartobjects.

I am brushing up on a couple things before I start digging into this project so I am hoping to gather some ideas before I get too involved with this.

13
Mamba
Re: "Universal" module framework...
  • 2010/8/5 2:53

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Quote:
And actually as I have already said i would be looking at taking more then one of these developer frameworks and combining them into one.

Excellent! I've added to the previous list of Frameworks couple more:

- RM Common Utilities
- WF-Resource
- SmartQbjects
- Phpp's Framework 2.30
- HappyLinux module 1.50
- Trabis's XMF (XOOPS Module Framework)
- RB Framework
- XAM Framework
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

14
redheadedrod
Re: "Universal" module framework...

Mamba, I will likely only use frameworks that I can install and test as it will be hard to test the final product against the original if the original doesn't work right.

I may look into them however and see if there are any additional classes etc that make sense.

Rodney

15
nmshah
Re: "Universal" module framework...
  • 2010/8/5 4:46

  • nmshah

  • Just can't stay away

  • Posts: 556

  • Since: 2007/7/2 8


@Mamba
You are trying to defend DJ maybe bcoz you know something that we dont but You still continue to fail to understand the problems of xoops community as a whole and by trying to keep one developer safe you are pushing away a lot of other developers

Can we pls keep this thread specific to the work being done on the "Universal" module framework and continue the other discussions about right and wrongs in xoops maybe in the old thread or somewhere else, so that people working on this framework can use this thread for discussions that can help them in developing this framework.

I am posting certain things that I will like to in the above mentioned thread.

Regards,
Nitin

16
Catzwolf
Re: "Universal" module framework...
  • 2010/8/5 4:47

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:

trabis wrote:
http://code.google.com/p/xuups/source/browse/trunk/modules/

I'm comiting xmf and xtest to Xuups repository as I type.

It has a lot of bugs, many typos. I'm mainly trying to structure this framework the way I would like Xoops to be structured. It is heavily based on smartobject and IPF.
I'm trying to favor composition over inheritance. There are some object helpers that can add behavior to objects on the fly, for example, objects can be initialized from an existing database table, title and description of object vars can be populated from a translation file, others to come...
There is the concept of object forms, object forms can recieve an object (previously decorated with an object helper) and render a full form based on the object settings. This way we favor configuration and convention and avoid the trouble of writing code.
There is also support for object datatypes (dtypes). Instead of being limited with int, textarea, textbox, url, ldate... we can drop other datatypes (currency, float, etc) with no need to hack any file.
There are classes for handling request validation, about pages, admin pages, etc

It is just an idea, I don't mind to trow this code to trash and pick a better one. It is just some food for thought.



Trabis,

Since we both know that most of your work and my work is mostly derived from the core in some form or fashion, please tell me why this should NOT be included within the core and part of the core?

We both know that it should be and I cannot fathom for my life why we are even entertaining this idea of a module framework that is separate from the core.

17
Catzwolf
Re: "Universal" module framework...
  • 2010/8/5 5:13

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Can you tell me which other developers were involved in any part of the development phases of Xoops version three? From any part of the 'development cycle'.

1. Initial planning.
2. Planning:
3. Requirements.
4. Analysis and design.
5. Implementation.
6. Testing/Deployment
7. Evaluation and then back to the start of the cycle.

With version 3, we are now on stage 6 of the process and only one person has anything to do with more or less all these steps and when you consider the amount of developers Xoops has or had, that is totally shocking and to be honest, if you cannot see this point I really do fear for the future of Xoops development.

1. Eduardo.
2. Alfred.
3. Trabis.
4. Formuss.
5. Wishcraft.
6. Kris
7. Kraven
8. Myself.

I'm sure that these people and many others which in my opinion could easily step up and be part of the core team (Which you yourself seem eager to promote, unless it is actually working alongside DJ on version 3.) and help Xoops to a brighter future.

Instead you have people working willy nilly on versions that hold no future, with no real roadmap and adding what they believe is right when they think it is right. If these versions hold no future, why waste time on them when version 3 is basically at the testing stage?

This has to stop, Xoops has to sit down collectively and work together in one goal with one vision and not as a bunch of individuals like we are now.

And as to regards to your comment about DJ having to come and fix other peoples work. If you had proper testing procedures and a quality of service for this area, these issues would have been found and corrected long before they where committed to the main branch.

18
Mamba
Re: "Universal" module framework...
  • 2010/8/5 5:17

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


John, as requested by Nmshah, can we focus on Frameworks here? This thread is NOT about X3.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

19
Catzwolf
Re: "Universal" module framework...
  • 2010/8/5 5:44

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:

Mamba wrote:
John, as requested by Nmshah, can we focus on Frameworks here? This thread is NOT about X3.


Actually, I think that the two should be hand in hand, and I think they are a lot closer together than you will ever care to admit.

But you go ahead and create your modular framework, and I can say outcome will be the same as when we discussed taking modules out of the core.

I feel we are making the same mistakes over and over again.

Selavi!

20
Mamba
Re: "Universal" module framework...
  • 2010/8/5 6:26

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Quote:
I feel we are making the same mistakes over and over again.

OK, John, you feel very strongly about the Framework, and I respect it.

So why don't we do that way that you suggested in your other message. Why don't you create this Framework, following 'development cycle' that you've mentioned:

1. Initial planning.
2. Planning:
3. Requirements.
4. Analysis and design.
5. Implementation.
6. Testing/Deployment
7. Evaluation and then back to the start of the cycle.

Please provide a roadmap/schedule and deliverables for each phase of the project, so we know what can we expect and when.

I also assume that you would engage authors of the other Frameworks to make sure that we have a good and solid Framework, that will be supported by the majority of the module developers.

Is it fair enough? Are you up to the challenge?

I think, once you show the analysis and design of the Framework, when you show the code, and a working example of a module, it might be easier to convince people that this is the right way to do it.

The one issue that we'll be facing is that on one hand you want to add a module framework to the core, but on the other hand people want to keep core "lean and mean", without any extra "fat". How should we merge those two conflicting requests? What if somebody doesn't want to use your Framework, but wants to use his own, or just the API directly? Why should we force that on him?

Adding a lot of code to the Core will create tons of dependencies and higher complexity, and higher chances to break things.

And how do we handle changes in the Framework, if there are no changes in the Core? Do we release a new version of XOOPS each time we make a change to the Framework. Will then people have to reinstall XOOPS every time it happens?

I think, we need to have something concrete, to touch and feel it, and to test it, in order to have better idea of the implications....
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

Login

Who's Online

208 user(s) are online (105 user(s) are browsing Support Forums)


Members: 0


Guests: 208


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Mar 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits