Modules, plugins & snippet optimisation ?

Quote from: garryn at Mar 12, 2006, 02:59 AM

Quote from: Guillaume at Mar 11, 2006, 11:32 PM

On the other hand, re group differents snippets (and others) in sub category can help users to choice or to found the must adapted snippet for his needs

I think that this will become easier when the main module, plugins and snippets Repository gets set up as this will provide all the necessary functions needed for people to be able to better find resources.

I personally like this idea, but it won’t be a substitute solution in combining several resources to have a more flexible resources. Here is the thing. Sometimes as the end users, it’s a lot harder to choose the right resources. Imagine if we have 3 different snippets that do almost the same thing, except the first one has a nifty features such as all the user interface being made with ajax, the other one with flash, and the other one aiming to a simplisistic. Now as the end users, when you have this 3 choices,to get what you really needed, you need to download and learn all this 3 different snippets, and finally figure out which one the best for them. It’s easy if it’s something like ajax, flash and bla2, that are popular and can be seen from the front interface, but if it’s something more internal, they will need to test them through. Now, don’t you think it’s a lot easier for users to learn newslisting and realize that they can do 3 different things with newslisting, instead of having to learn 3 different snippets that later they only need to use one of them, and the time that they spent in learning the other two is a waste for them.

But I can also see your point. I believe more opinion from the community will be great. It’s great to see different opinion and suggestion.
Here is the list that we have so far of what we are planing to do:

• Categorize repository
• SVN repository for resources to allow better team collaboration for each core developers for resources
• Standard guidelines to submit resources
[li] Labeled all current resources:
[list]

• Official - MODx official resourcesdistributed with MODx official released package
• Approved - MODx approved resources that had passed sanity check and released as stable release, not alpha/beta
• Community - Resources released by community that is stable and had been used by several people with no problem.
• Pre-release - Resources that are being developed by community/advanced users that are still under heavy development (alpha or beta version)
• Project - New idea that are still under development with no major alpha release yet

[/li]
[li] Ensuring the development of resources, by selecting core coder for specific resources[/li]
[li] Have a team of developer to do sanity/performance check to the resources[/li]
[/list]

All the tasks above can be summarized into 3 different major tasks that need to be done.

• Building standard guidelines and core team in maintaining the resources.
• Building MODx repository for snippets, plugins, modules, and templates. A better integratioin with forum and MODx based user, which includes commenting and rating maybe.
• Building resources installer built into MODx, with a clear defined guidelines on how the resources needs to be packaged.

UPDATED: 3/12/2006

I don’t think fusion snippets but categorize them to make easy research of snippets and to make easy comparison.
For example, I use NewsListing to display a list of summarized articles. I use it also to display count of comments. But to display a complete article, I don’t need NewsListing and I want to display count of comments : I used UserCommentsCount (it make only that I need, not more).
It’s not useful to load a big snippet to use a little functionnality.

phpGiggle permit to transform text to link everywhere the text is found. I have write a snippet AutoLinkRef wich create link from tag. This snippets are similar but have not the same use. In this case, fusion the 2 snippets can be interesting because the core of this do not have very different and only few lines must be different.

SVN repository for resources to allow better team collaboration for each core developers for resources

Sorry, I don’t understand "SVN" is.

Standard guidelines to submit resources

It seems be interesting but I don’t see which "lines"

Labeled all current resources with official, tested, not-tested, pre-release (a better naming and labeling idea is needed)

And "Modx approved"

Ensuring the development of resources, by selecting core coder for specific resources

I don’t know why select coder ? Developpers who submit ressources have not posibility to code their ressources ?

Have a team of developer to do sanity/performance check to the resources

This team could not do performance check to validate but, during verification of sanity, they can "analyse" code to verify if method used seems the best, and indicate if other solution seems better.

By the way, fusioning two snippets such as phpGiggle and AutoLinkRef will not be a wise decission
That’s the reason why we need several guideline and a solid team that know what needs to be done. Come up with the guidelines will take some time, so it’s better if we just start the project in doing snity check and bla bla bla for all the current resources, while waiting for the new resources repository to be developed. Down the road, people like you, me and the other resources developer able to chip in their idea, and we all will come up with the limit between where the fusion of snippets is needed, or how to use best practices when building new resources and etc.

Sorry, I don’t understand "SVN" is.

SVN is called subversion. It’s another way to keeping track code changes that does more than CVS, like the one being used on sourceforge long before they make SVN available. It’s a good way to start, so in case some other developers messed up the code, or we are going to release the code without releasing the current development version, so we use the stable one, and it all can be controlled by SVN

Quote
Standard guidelines to submit resources

It seems be interesting but I don’t see which "lines"

One of the best example that we need to have will be the commenting guideline for snippets, plugins, modules, and templates. The top commenting format will looks a lot better if we have a standardize way to put description, copyright/credits, installation note, usage description and examples, revision history, and download location. If we have a standard format/guideline, a new user to MODx will be able to adapt to the current resources much faster.
Another thing will be the resources packaging, considering we are about to develop our own in house resources installer, which standardization of the folders hierarchical, installatio notes, and etc will be great, so by the time we have the new resources installer, we can easily adapt the current resources that we have to be used on that installer, just like what phpBB does.

This team could not do performance check to validate but, during verification of sanity, they can "analyse" code to verify if method used seems the best, and indicate if other solution seems better.

That’s so true, but if they follow best practiices and pass some of the sanity check, usually it will result in a much faster performance, but it might be wrong, considering abstraction sometimes causing the system to bogged down a little bit. But most of the time, as a fellow programmer, you know whether the system will be bogged down by the performance issue or not. So having a well trained advanced user in this area will be great.

OK, cut the chit chat, lets get started on the things that we need to do.
Guillaume, when you start this topic, I believe you already have a few things in mind before you posted your suggestion. Do you mind organizing all that idea of improvement that can be done in a well summarized form that we can read and organize it? I will try to keep the top list up to date, and we’ll stat moving on.

Garryn, or some other resources developers, are you guys willing to chip in into this? I know you guys are all busy with building a custom solution on top of MODx, like what I did right now, but if all the advanced users in this forum (which includes all users, not only the one having a MODx badge or whatever) we will have this project/plan to be done a lot faster.
I listed 3 big tasks that needs to be done on my previos post, and I’ll keep it updated, until we have gather enough people to move forward, then we will request Ryan to create a subforum that can be moderated by some of us, and we will start maintaining and doing all the heavy task to ensure the best extension being delivered to our end users.

Thanks

http://subversion.tigris.org/

i utilize tortoise svn. Very easy to use
http://tortoisesvn.tigris.org/

Recently I have problems to format date in french localization. I would like display "mecredi 18 février 2006" (textually "wednesday 18 february 2006". Is it possible to intervene with the core team to they add a core function to display correctely dates with localization for the next release ? For example a function like
To resolve my problem I have write a snippet (FormatDate) that I propose to use to manage date formatting.

I think we will need a lot of cleaning on MODx core before we can add this functionality. First, we need to remove all hardcoded string, second we need to remove all hardcoded path, thir we need to replace all date time format using setlocale enabled, so we can get the right output for each date, fourth, we need to revamped the api to allow more abstraction to be used by resources developer, and the last one will be manager overhaul. Pheewww... Hope I got everythings down.

Few ideas for guidelines :

In PHP code

Use single quotes instead of double quotes => ’some text’ is parsed faster by php core

Use concatenation instead of variables into double quoted string => ’some text’.$var is parsed faster by php core

All variables must begin with initials of the ressource name => variables identified like that will defined in snipppet

Name of variables should be formated with "specific grammar" => easier read of code
This "grammar" should be defined later, it is an idea not an obligation in this exemple.
I use str for string, nr for initials of the ressource

Same thing for functions.

Variables should be declared or initialized before using it => not possibility to inject value into ressource variables

Variables and objects created during the execution of the ressource must be destroyed => free memory is always good
Memory freeing can be make when variables or objects are not used after

Not used values past in parameters without validating their format => avoid assigning to a string a date.
I don’t know if it is possible to make it easly with Modx (without write functions to validate)

Parameters must have default value in ressource core => avoid bug if param is not initialized

Snippets and plugins must not containe (x)html but they must include template or chunk => Simplification of translation

Use strftime() to format date instead of date() => internationalization of date
strftime() is affected by set_local() whereas date() is not
The best is used core function to manage charset in the same time : strftime() return dates in ISO-8859-1. A substitution of croe function (while waiting it) is my snippet FormatDate

Included files of functions or core snippets by include(’......’) to display the minimum of core code in the textarea ressource => in the absolute, only header and parameters should be displayed in this textarea (avoid error when user modifiy parameters)

Use include_once() instead of include(), require(), require_once()

PHP comments
Create an header with :

• Ressource name
• Author name
• Author nick (if exists)
• Version
• Date of the first relesaed
• Date of the current released
• Short description
• Long description
• Some exemples of uses with explications
• List of parameters and explications of them
• List of modifications (bugfixes, new functionnality, rewrited portion of code)
• List of chunk or template used by default
• List of files of ressource needed to run ("all files into xxxxx folder")
• List of files needed to run ("all files into xxxxx folder")
• Modx version compatibilty (I think to uses of core function)
• Todo (if ideas)
• Dependencies (like my snippet for the date )

Separators to indicate begin and end of parameters => it can be used later on to parse code and extract parameters. For example :

/////////////// Parameters begin //////////////
some parameters
/////////////// Parameters end //////////////

Many comments in code (not necessary but more comments is better than no comments) => only recomandation


It is my first vision.

Take care.

Thanks so much for these suggestions... a great start indeed.

That’s a fabulous job that you did. I can see that you already have all those things planned out before.

I haven’t read the qholre guideline, but reading the first few lines, I cannot be more agree to some of those tips. Lets work on this together, by the way, where is the other resources developers for MODx? I’m hoping to see them involve in the discussion more, so we can get this tarted without depending on me and you only.

Btw, can you explain it a bit detailed about setlocale in PHP, and what’s the best practice that we need to take, so we can implement it to the core, as well as to the resources that we have currently. I believe we all would love to know more about this. A detailed step that needs to be taken in creating a multi lingual resources will be great, but this is only for date and currency I believe, considering that’s the two major things that needs to be tweaked from inside of the code.