Call for Help for 1.6: Implementing and documenting JError Codes
Hannes Papenberg
1.6 is making big leaps at the moment and as it was announced before, we
don't want to sit in our dark rooms and code just among ourselfs. No, we
want you to get involved. We want feature patches, bug fixes and
involvement in discussions.
We have some areas that just require a ton of work and where you can
help even without a ton of knowledge about the system. One of those
areas are the JError errorcodes. We throw a lot of errors in Joomla here
and there, but up till now, those were almost always just with the code
0 and some unhelpfull message. We now want to change those to a
documented errorcode system. For this, we have the following page on our
wiki:
http://docs.joomla.org/Errors
On that page you see a list of numberring ranges for the different parts
of Joomla, starting with the framework and then the different
applications. Below that list, you can see which error codes have been
implemented so far. What we would like to have is every developer, that
has half an hour of time, to dive in, take one subpackage of Joomla,
change the error code to something meaningful, document it on the wiki
and send in a patch via the Feature Patch Tracker.
So, how do you do this? First of all, you decide which package you want
to do. Just choose one of the packages listed on
http://docs.joomla.org/Errors in the "Ranges for Error Numbers" section
and send a mail over the list, that you are working on this one to make
sure that two people are not working on that part at the same time
Now you go through the code and wherever you find something like this:
JError::raiseNotice(500, JText::_($this->ErrorInfo));
Replace the number with one from the numberrange for that package and
put a meaningfull message in there, followed maybe by the
$this->ErrorInfo part. Create a patch from this and save it to your
harddrive. A patch can be done this way:
http://docs.joomla.org/Creating_a_patch
Now this number itself wouldn't help us a lot, we need to document this
properly. This is done on the wiki. So, log in and create a new page for
that error with the following scheme:
http://docs.joomla.org/Errors/<ERRORNUMBER>
Just type that into your adress bar and then create the documentation
for this error number. How should such a documentation look like? Take a
look into the discussion area of this site:
http://docs.joomla.org/Errors There you can find a template code for the
documentation. Just copy this one to your new site and fill in the
correct data. After creating this page, send in the patch via our Joomla
1.6 Feature Patch tracker on Joomlacode and we will apply it as soon as
possible to the trunk. You can find the Joomla 1.6 Feature Patch tracker
here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8549
Sometimes the numbering range is not large enough to accomodate all
error messages in one subpackage. In that case, when you have reached
the end of the range, you start again at the beginning and add a .01 to
the first error code and then we start to count up from there. So we
would have Errorcode 1050.01, 1050.02, etc.
Now, for one developer alone, this is impossible to do all by himself,
but if everybody could help out with just one package, we would have
this done in just a few hours. For now it would just be awesome if we
could get the Joomla framework done. If that has been achieved, we can
go further and do the different applications and components.
This is the perfect opportunity for you to start messing around with the
Joomla codebase, getting to know the code intimately and maybe you find
something that you want to implement besides this for 1.6. So help us
out, lets show that Joomla does not only mean "all together" translated
into english, but that we also act by that!
Hannes
P.S.: If you have another feature that you coded and want to see in 1.6,
add it to the Feature Patch tracker, too and contact us to add it to the
trunk, so that everybody can benefit from this. :-)
Hannes Papenberg
/libraries/joomla. So for the Backup range from 1000-1049, you would
have to check all files in the folder /libraries/joomla/backup
Hannes
Hannes Papenberg schrieb:
Amy Stephen
Thanks for providing good documentation and an easy way for people to jump into Joomla! 1.6 development.
If people want documentation on getting set up for development, check out http://docs.joomla.org/Developers#Contributing_to_Joomla_Development .
In it, you will find instructions for how to download and install Eclipse, if necessary, and also how to connect to the Joomla! 1.6 SVN so you can start on this task.
This is a really good task for people who *want* to get involved in the development but think they will need help getting started.
So, if you want to try, and you think you'll have lots of questions, this is the one to help with! Just this list. When your ID is approved, post into this thread and introduce yourself. Ask questions in this thread. We all have to learn to walk before we run - and we want lots of people running, so, it's worth it to invest in helping you become a contributor. Please give this a try if you've always wanted to be a part. Now's the time.
Thanks!
Amy :)
Chris Davenport
Chris.
Hannes Papenberg
Hannes
Chris Davenport schrieb:
>
> Chris.
>
>
Chris Davenport
I was just thinking that numbers don't convey much information in themselves and we have the opportunity to make the error codes more meaningful. For example, we could namespace the error codes, like this:
Backup/1298
Application/2983
JSite/8212
You'll never run out of numbers so you don't have to worry about reaching the end of a range. Using a "/" as a separator also has the advantage that MediaWiki uses it to indicate sub-pages, so we can automatically generate lists. We already do that for the "List of errors" on http://docs.joomla.org/Errors but that list is going to get *very* long with all the new error codes listed. It would be nice to break that list into something more hierarchical.
To make this even more meaningful you could use the @package/@subpackage hierarchy, so you get error codes like this:
Framework/Filesystem/2393
Framework/Application/8723
Joomla/Contact/7372
This also gives 3PD's a natural way of integrating their own error codes.
Another simple idea is that when the error code/message is displayed to the user (assuming it is, of course), the code is made into a hypertext link that takes you straight to the relevant page on the wiki. By encouraging people to comment on the error pages we can build up a knowledge base of causes and remedies.
With a bit of thought and very little effort we can make the error coding system into something quite powerful. Incidentally, it is best to avoid putting "." into wiki page titles. We have a mod_rewrite rule that makes it possible to do it in the English wiki, but for the translation wikis I'm trying to avoid the necessity for special mod_rewrite rules.
Well, that's my thinking anyway. ;-)
Chris.
Sueter
I’m willing to help on documenting the JError codes.
Are you going ahead with straight numbers or are you thinking about implementing chris’s idea? I think the idea of breaking it into the different areas with a meaningful apha prefix makes a lot of sense. Then just seeing the code you know where you are which is an advantage.
I’ll do Forms.
Andy
D O T E A S Y - "Join the web hosting revolution!"
Damien
as of yet done any editing though.
I think Chris's idea could work in theory but it more of a
documentation case. I think the best bet would be
to have a separate page for each area of the framework and components
that would then have the list of error codes
listed within. Thus the wiki would be more organized. The structure
could look like:
Errrors -|
|- Application-|
| | - AppErrors
|- Backup -|
| | - BackupErrors
The result would be fairly well structured wiki doc for the various
areas of the code.
Thoughts?
On 13 Apr, 15:05, "Sueter" <sue...@andytarr.com> wrote:
> I'm willing to help on documenting the JError codes.
>
> Are you going ahead with straight numbers or are you thinking about
> implementing chris's idea? I think the idea of breaking it into the
> different areas with a meaningful apha prefix makes a lot of sense. Then
> just seeing the code you know where you are which is an advantage.
>
> I'll do Forms.
>
> Andy
>
> _____
>
> [mailto:joomla-...@googlegroups.com] On Behalf Of Chris Davenport
> Sent: Saturday, April 11, 2009 7:27 AM
> To: joomla-...@googlegroups.com
> Subject: Re: Call for Help for 1.6: Implementing and documenting JError
> Codes
>
> Hehe. Well, even strings can be unique. :-)
>
> I was just thinking that numbers don't convey much information in themselves
> and we have the opportunity to make the error codes more meaningful. For
> example, we could namespace the error codes, like this:
>
> Backup/1298
> Application/2983
> JSite/8212
>
> You'll never run out of numbers so you don't have to worry about reaching
> the end of a range. Using a "/" as a separator also has the advantage that
> MediaWiki uses it to indicate sub-pages, so we can automatically generate
> something more hierarchical.
>
> To make this even more meaningful you could use the @package/@subpackage
> hierarchy, so you get error codes like this:
>
> Framework/Filesystem/2393
> Framework/Application/8723
> Joomla/Contact/7372
>
> This also gives 3PD's a natural way of integrating their own error codes.
>
> Another simple idea is that when the error code/message is displayed to the
> user (assuming it is, of course), the code is made into a hypertext link
> that takes you straight to the relevant page on the wiki. By encouraging
> people to comment on the error pages we can build up a knowledge base of
> causes and remedies.
>
> With a bit of thought and very little effort we can make the error coding
> system into something quite powerful. Incidentally, it is best to avoid
> putting "." into wiki page titles. We have a mod_rewrite rule that makes it
> possible to do it in the English wiki, but for the translation wikis I'm
> trying to avoid the necessity for special mod_rewrite rules.
>
> Well, that's my thinking anyway. ;-)
>
> Chris.
>
> To make sure that they are unique: yes. :-)
>
> Hannes
>
> Chris Davenport schrieb:
>
>
>
> > Just a thought.... Do the error codes *have* to be numbers?
>
> > Chris.
>
Ercan Özkaya
Exception is an integer. To make each package has enough space for
storing each error message we are going to use a 6 digit number.
We gave this another thought and decided on the following convention:
If we call it xyyzzz:
x is for scope. We are going to use 1 for framework, 2 for application
level and 3 for core extensions.
yy is for package. In framework's case above ranges for packages will
be replaced by 01, 02 etc. (We'll update them in the wiki in a bit so
you can eventually start working on JForm.)
zzz is for actual error message itself.
This way we can also create ranges for each third party application
out there later.
And Sueter thanks for helping out. This is an area where we need help
A LOT. It's much appreciated. :) Feel free to contact me if anything
is not clear.
Ercan
On Apr 13, 10:05 pm, "Sueter" <sue...@andytarr.com> wrote:
> I'm willing to help on documenting the JError codes.
>
> Are you going ahead with straight numbers or are you thinking about
> implementing chris's idea? I think the idea of breaking it into the
> different areas with a meaningful apha prefix makes a lot of sense. Then
> just seeing the code you know where you are which is an advantage.
>
> I'll do Forms.
>
> Andy
>
> _____
>
> [mailto:joomla-...@googlegroups.com] On Behalf Of Chris Davenport
> Sent: Saturday, April 11, 2009 7:27 AM
> To: joomla-...@googlegroups.com
> Subject: Re: Call for Help for 1.6: Implementing and documenting JError
> Codes
>
> Hehe. Well, even strings can be unique. :-)
>
> I was just thinking that numbers don't convey much information in themselves
> and we have the opportunity to make the error codes more meaningful. For
> example, we could namespace the error codes, like this:
>
> Backup/1298
> Application/2983
> JSite/8212
>
> You'll never run out of numbers so you don't have to worry about reaching
> the end of a range. Using a "/" as a separator also has the advantage that
> MediaWiki uses it to indicate sub-pages, so we can automatically generate
> something more hierarchical.
>
> To make this even more meaningful you could use the @package/@subpackage
> hierarchy, so you get error codes like this:
>
> Framework/Filesystem/2393
> Framework/Application/8723
> Joomla/Contact/7372
>
> This also gives 3PD's a natural way of integrating their own error codes.
>
> Another simple idea is that when the error code/message is displayed to the
> user (assuming it is, of course), the code is made into a hypertext link
> that takes you straight to the relevant page on the wiki. By encouraging
> people to comment on the error pages we can build up a knowledge base of
> causes and remedies.
>
> With a bit of thought and very little effort we can make the error coding
> system into something quite powerful. Incidentally, it is best to avoid
> putting "." into wiki page titles. We have a mod_rewrite rule that makes it
> possible to do it in the English wiki, but for the translation wikis I'm
> trying to avoid the necessity for special mod_rewrite rules.
>
> Well, that's my thinking anyway. ;-)
>
> Chris.
>
> To make sure that they are unique: yes. :-)
>
> Hannes
>
> Chris Davenport schrieb:
>
>
>
> > Just a thought.... Do the error codes *have* to be numbers?
>
> > Chris.
>
Erdősi Gergő
but kept the old documented error numbers, however they should be
renamed later to the new error numbers.
2009/4/13 Ercan Özkaya <ozkay...@gmail.com>:
Erdősi Gergő
http://www.joomline.hu - Joomla! fejlesztői oldal
Chris Davenport
Chris.
Sueter
I'm assuming we'll want a place that they are all entered to make it
easier for people to translate.
Thanks,
Andy
On Apr 13, 7:22 pm, Chris Davenport <chris.davenp...@joomla.org>
wrote:
> integers, but we can't have everything. ;-)
>
> Chris.
>
>
>
> > I updated the wiki with the new ranges:http://docs.joomla.org/Errors,
> > but kept the old documented error numbers, however they should be
> > renamed later to the new error numbers.
>