1
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!



2
Catzwolf
Re: Problem with Xoops CODE tag
  • 2010/8/5 5:16

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Is there any chance I can have a look at what you are trying to do here? Can I see the code please? Sometimes a fresh pair of eyes on something helps :)

Catz



3
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.



4
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.



5
Catzwolf
Re: "Universal" module framework...
  • 2010/8/4 18:57

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


The best-laid plans of mice and men often go awry

When developing any software, there is a technique called the development cycle. This outlines the basic structure that all developers should follow and is one of the most important elements within Xoops that has been missing for a long time.

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://www.pd-how2.org/1_2.htm

1. Development Team: What's the point of having a saddle if you don't have a horse? All the plans in the world will mean nothing, if you do not have the team in place to carry them out.

Should this team be the core development team or module developers? It should lie firmly at the door of the core and there are a number of very good reasons for this:

• Most of the main classes, methods and files are already situated within the core and would require little tweaking. If we do this within a module framework outwit the core, we again will have to split most classes, functions, and files up, and this would mean double the work and out of all these, XoopsObject and XoopsObjectHandler comes to mind straight away.

Just about everything within Xoops now runs through the two classes I have mentioned, it seems illogical to me to have two different versions of the same classes being used within the same system, basically, one for modules and one for the core. To me, this is impractical for all concerned.

Another variable you have to take into consideration is this, when a class or function is part of the core, this is generally considered the correct way of adding functionality to your module. For example: Notifications or group permissions. Generally, I will write new code only if the core cannot provide me with a real solution, or there is a bug or the code is too restrictive in its approach.

• Who will maintain this framework? If you are suggesting that module developers should maintain this library, I would suggest you rethink that approach. One thing is certain here, module developers come and go, modules fall off the map, but the core will continue even after a developer quits. Ask yourself this question, what is the current state of the modules that were part of the core and yet, module developers were ‘asked‘ to maintain those modules, but that never happened? What makes you think this will be any different?

2. Follow the development Cycle: Xoops is a large-scale project, yet it’s being treated daily like someone’s private own script with no real organisation or thought process. When was the last time that the roadmap was last revised? In fact, when was the last time that there was any meeting to actually discuss in any great detail to what is required of Xoops and how to actually go about adding new features, fixing old ones and removing obsolete code? This certainly did not happen with Xoops v.3.

There are rules and guidelines that must be adhered to when you have (or should have) many different people working as a team within the same project and yet, Xoops as a project ignores these principles, but yet, I’m still getting asked to design unit tests on code that was never designed to run unit tests in the first place.

For the last six to seven years I have been saying the exact same thing, things have to change, because the way we currently are doing things is wrong on so many different levels. There is no development cycle, no real structure, and no delegation of tasks and when people do offer to help, they are generally left out in the cold and in most cases, just walk away.

You say you want a framework. So do I am many other developers, but the biggest difference is in the way we both think it should be done. I am saying no to a modular framework, because I believe it is the wrong way forward for exactly the reasons I have stated already and I believe that if this if going to be done correctly, it should be within the core and maintained by the core.

I think am really done trying to get changes here, and personally I’m getting sick and tired of constantly having to butt heads with people over what should really be normal working practice in a community like this. The people I feel sorrier for the normal users, who just want to have their websites with good working modules.







6
Catzwolf
Re: Deprecated method replacements?
  • 2010/8/4 17:44

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:

Peekay wrote:
That's great catzwolf, many thanks indeed

Quote:
use PHP native htmlspecialchars() rather than the one provided in $myts.

Do you recommend this for all instances where htmlspecialchars is the replacement? Is there a problem with the sanitiser version?


Yes I do, I don't see the need of loading a entire class just to use one function, especially when the php equivalent has the exact same functionality.

I would have said the same about stripslashes and addslashes as well, but due to the different server set-ups, the actual $myts version is more appropriate. I cannot wait to see the back of these two functions, they have caused developers more headaches than they are worth.



7
Catzwolf
Re: Deprecated method replacements?
  • 2010/8/4 16:39

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:
MyTextSanitizer::codeSanitizer()


There is no alternative to this.

Quote:
MyTextSanitizer::sanitizeForDisplay()


use MyTextSanitizer::displayTarea()

Quote:
MyTextSanitizer::sanitizeForPreview()


use MyTextSanitizer::previewTarea()

Quote:
MyTextSanitizer::oopsStripSlashesGPC()


stripslashes is regarded as deprecated as of php 5.3, but until the time useMyTextSanitizer::stripSlashesGPC()

Quote:
MyTextSanitizer::oopsStripSlashesRT()


same as above

Quote:
MyTextSanitizer::oopsAddSlashes()


MyTextSanitizer::addSlashes();

Quote:
MyTextSanitizer::oopsNl2Br()


MyTextSanitizer::nl2br();

use PHP native htmlspecialchars() rather than the one provided in $myts.

if you are not going to use XoopsObect class for dealing with saving to database, do not use addslashes use mysql_real_escape_string



8
Catzwolf
Re: "Universal" module framework...
  • 2010/8/4 9:04

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:

Balzac wrote:
Therefore some module developers created their own specific framework. Which in fact is absurd.
One universal module framework can solve this whole module and compatibility mess.


It is really quite clear that you have no idea what you are talking about do you or you wouldn't be sitting there writing this?

Now I am going to defend every module developer out there who has HAD to use their own framework, it was born out of necessity and not pride or nor vanity.

The core has been neglected for the last five years, we have had to find our own solutions to problems that has either been caused by the lack of interested or by the bugs that are in the system already.

If you had any IDEA what so ever the problems faced creating modules on en-mass you wouldn't be sitting there stating what you just did.

What would sort out this whole mess, if the core took one little bit interest in actually working with us, rather than against us and it worked pretty darn well when Ono was the lead developer. Least he understood the importance of modules.




9
Catzwolf
Re: Problem with Xoops CODE tag
  • 2010/8/4 2:18

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Peekay,

There are a few places where different code is being used to more or less do the same thing here.

If I understand you right, you need to look in Xoops Forms and formdhtmltextarea.php, there and also in the 'includes' folder you should find xoopscodes.php which more or less has the same code.

You also might want to look in the
class/module.textsanitizer.php and all the plug-in for that. Plus, the module that you are using could possibly have the same code that is used by all the examples I have given you.

But from what I can see, it looks like that $myts is finding something in the input that it doesn't know how to handle correctly. Maybe an unclosed tag or misplaced quote or something.

I have a funny feeling that
lor="#000000"


Could in fact be
color="#000000"
or
backgroundcolor="#000000"


So I would look for that in your code somewhere.



10
Catzwolf
Re: Deprecated method replacements?
  • 2010/8/4 0:25

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Plus, many of what are being called depreciated, In my eyes shouldn't be and many others actually while being called depreciated have no real alternatives. (Unless you do it yourself, which seems to fast becoming the motto of Xoops) .




TopTop
(1) 2 3 4 ... 185 »



Login

Who's Online

181 user(s) are online (59 user(s) are browsing Support Forums)


Members: 0


Guests: 181


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