-
Re: 1.5 Branch Freeze Announcement
And 1.5.8 is out. We're unfrozen... Fix away!!!
-
Re: 1.5 Branch Freeze Announcement
Thanks for the heads up ... :D
I will see if I could fix some other minor stuff for next nextrelease.
-
Re: 1.5 Branch Freeze Announcement
Yes, we had looked at that prior to the freeze going into effect, and
decided to delay it since Airton and a few others found issues with the fix
(possibly not related to the fix, but it's an issue none the less). We
decided to delay the fix to 1.5.9 so it can be fixed once, and completely...
-
Re: 1.5 Branch Freeze Announcement
oops ... I am late to commit this tiny change.
[link]
-
Re: Exceptions: classes or codes?
I think you pretty much nailed the best answer - there's no clear
winner. I think error codes is fine, unless you find yourself having to
duplicate code for some class of exceptions, in which case a derived
exception class may be better.
ROSCO
-
Re: Exceptions: classes or codes?
Actually I think either technique has its uses.
Maybe we can think in terms of the extended exception classes being
thrown at the "API" level. This is, the class method is used to throw
exception from the database, or a component, etc:
JExceptionDatabase (sql error, connection error, etc)
JExceptionComponent (can't find you, can't find your view, etc)
-
Re: Exceptions: classes or codes?
Well, if we don't now by that logic, we can never use exceptions. That's
because the "legacy" extensions won't have the code to catch them. But,
with that said, the only way an extension should "see" an exception, is in
an error event. So they can't gracefully handle errors... 1.6 enabled
extensions will REALLY be able to handle them well! I don't think it's
-
Re: Exceptions: classes or codes?
Ignore, always. Throwing exceptions will destroy any attempt at a
legacy mode. I've been programming exclusively on PHP5 for a while
now and I can't see any way that someone's legacy code ( ie no catch()
{} ) could accommodate a use throwing an exception within the
framework. Sux, I know, but we need to make a smooth transition.
-
Exceptions: classes or codes?
As we introduce exceptions to the core, there are two ways to handle a
fairly common situation. I'll explain by example. We have this (valid)
code in JStdClass:
public function setProperties( $properties )
{
$properties = (array) $properties; //cast to an array
if (is_array($properties))
-
1.5 Branch Freeze Announcement
The 1.5 branch will be frozen at the following date and time:
[link]
-
Schema Changes
Hi there,
For all of those kids playing in the trunk sandpit, I've destroyed the
"plugins" table due to an immense disgust with the thing. To put it
blunt: it had it coming and is now replaced with the much cooler and
mildly generic "extensions" table. Extensions now absorbs plugins (it
was originally modelled of it) and will become your one stop shop for
-
Re: RFC: Coding standards update
Couple of extra minor additions.
1. How to annotate language string with more than one printf style replacement.
2. A condensed header block for layout files.
Regards,
Andrew Eddie
2008/10/21 Andrew Eddie <mambob...@gmail.com>:
-
Re: RFC: Coding standards update
Ross, my preference is "it depends". If you look at the sort order, I
like to alphabetically group all column headings (hence use a common
prefix) but with say a field name and a field description, I use a
suffix because those contextually belong together.
It's probably 6 of one, half-dozen the other - as long as we are
-
Re: RFC: Coding standards update
Only question I would have here is why not
WEBLINKS TITLE COL=Title
COL is a "modifier" of WEBLINKS TITLE, similar to DESC, just seems more
logical to me for it to come at the end. I would also prefer to see it
spelt out COLUMN - never know when you might want to add colour ;)
ROSCO
-
Re: RFC: Coding standards update
Packages/subpackages: sounds good. Worthy of noting that PHPDocumentor
likes these tags in the class doc block, rather than the file header.
Message name spaces and variables: ++ and ++
The only suggestion I would make is that we formalize the hierarchy
and delimit with some agreed upon character, which would give us
-
Re: Redux : Putting Joomla! 1.6 on a diet
Not that I'm particularly attached to phpmailer, though I did just
look it up and the latest release for PHP5 would appear to be July of
this year. Beyond not being updated in years and prone to security
issues what advantages does SwiftMailer have over PHPMailer? If we
deprecated PHPMailer in 1.6 it would mean we should still keep it
-
Redux : Putting Joomla! 1.6 on a diet
Hi guys,
With the activity on 1.6 development taking up again I though it to be
good to post a followup to the discussion I started in May this year
about the removal of legacy libraries and legacy code from 1.6. The
original thread can be found here :
[link]
-
Re: RFC: Coding standards update
Couple of other things I've been thinking about is package and
subpackage formats.
What do you think about the following:
PACKAGES AND SUBPACKAGES
Frontent component
@package Joomla.Site
@subpackage com_weblinks
Backend component
@package Joomla.Administrator
@subpackage com_weblinks
XML-RPC application
-
Re: RFC: Coding standards update
Ok, running summary.
@ CamelCase
I'm actually with Alan on this one. I would actually prefer JHtml,
JXml and so on.
@Assignment
For me
protected $foo = 'bar';
is preferred. Let's just set it to that.
@ Comments
I personally only use the /* */ style in DocBlocks. Otherwise, even
for multiline, I use //. I find it's more consistent reading (that
-
Re: RFC: Coding standards update
I have the beginnings of a CodeSniffer rule set customized for Joomla.
Once we've worked out all the gritty details here, I'll update them
and post them to SVN (somewhere under testing).
-
Re: RFC: Coding standards update
A convenient exception to the camel case rule won't stop some
automated tool from looking for JHTMLSelect in /libraries/joomla/h/t/m/
l/select.php. If we're consistent now, we can avoid having to code
special cases for whatever might come up in the future.
When it comes to obscure snippets of disabled code, I in agree 100%.
-
Re: RFC: Coding standards update
I have always wondered why plugin class names were seemingly exempt
from the naming standard. They should be PlgGroupName, right? Was
there a reason for naming them plgGroupName or just an unfortunate
mistake?
Also, what is the strategy for fixing these errors in the code - a
branch, working directly in the trunk... ? I ask because I can
-
Re: RFC: Coding standards update
I agree whole heartedly on && vs AND... && is a logical operator, and
there's no mistaking it...
I'm not a fan of any extra whitespace... To me
protected $foo = 'bar';
is 10x more readable than
protected $foo = 'bar';
sure, it may not look as uniform, but I think it's easier to read...
-
Re: RFC: Coding standards update
Amongst the things I'm personally not fond of, only two stand as
worthy of comment.
1) I strenuously object to AND and OR over && and ||. People forget to
uppercase them, which makes a mess. I don't think they improve
readability, it makes code look more like a SQL query.
2) This convention of adding extra whitespace before an assignment to
-
Re: RFC: Coding standards update
Hi Andrew,
In the "Indenting and Line Length" section, there is a small typo
("reabable" instead of "readable") but unfortunately I can't correct
it right now (tried editing twice but every time the save fails).
Probably my connectivity - am up in Africa at the moment.
In the first example under "Control Structures", the opening "{" is
-
RFC: Coding standards update
Hi all.
Joomla (and Mambo before it - well, up until we left and then things
sadly when downhill) has always had a strong attachment to well
formatted code. Our guidelines have been in place for many, many
years and were originally based mostly on the PEAR standard. Since
then the PEAR standard has changed and I've update the standards to
-
Re: Dev WG Meeting
Quick Summary:
1.5: After 1.5.8, We're slowly going to start to slow down the maintance
procedures (move all priority 4 + 5 to 1.6, be selective about what priority
3 get fixed..
1.6:
Refactoring branch being merged to trunk
Cache, Media, Translation and Update branches being merged to trunk
-
Re: ACL?
We'll talk about it in a few hours.
Regards,
Andrew Eddie
2008/10/7 Hannes Papenberg <hackwa...@googlemail.com>:
-
Re: Dev WG Meeting
Anyone else who's not there, just ping me on skype, and I'll add you...
-
Re: Dev WG Meeting
I'll also be there. Can you please add me too?
Ercan
2008/10/15 Anthony Ferrara <ircmax...@gmail.com>
-
Re: Dev WG Meeting
Might want to add me too.
Rob
-
Re: Dev WG Meeting
Skype chat. I didn't realize you wern't in yet. I'll add you in now...
-
Re: Dev WG Meeting
Where will this meeting take place ?
Johan
On Oct 15, 5:30 pm, "Rob Schley" <rob.sch...@community.joomla.o rg>
wrote:
-
Re: Dev WG Meeting
I will do my best. That is earlier than I am normally capable of getting up
but we will see.
Rob
-
Re: Dev WG Meeting
I should be there also.
Ian
On Tue, Oct 14, 2008 at 11:51 PM, Toby Patterson
-
Re: Dev WG Meeting
Ditto.
-
Re: Dev WG Meeting
I'll be there.
Regards
Andrew Eddie
2008/10/14 Anthony Ferrara <ircmax...@gmail.com>:
-
Re: Dev WG Meeting
I wont be able to attend either because I am giving my internship oral
presentation at the university exactly at that time.
Chantal
-
Re: Dev WG Meeting
It's 6 AM here. I am barely wake up and have to get ready for work.
I guess I can't make it too.
-
Re: Dev WG Meeting
I won't be able to be there, all input will be shared upfront.
Regards, Wilco
-
Re: Dev WG Meeting
Hi Anthony,
Unfortunately I will be traveling on Thursday so will be unable to
attend. Please post a summary if possible and I will give my input (if
any) as soon as I get online again (should be Friday).
Best Regards,
Charl
-
Dev WG Meeting
Well, it's time... 1.6 is coming together... Momentum and buzz is starting
to build... That's why I'm calling for a dev wg meeting. PLEASE try to
make it. If not, I'll post a summary to the group...
[link]
-
Re: 1.6 backend configuration
This probably relates to the refactoring of the install so I'll look
at this.
Toby
-
Joomla! Commits Mailing List
Commit junkies, do I have the offer for you!
Ever find it hard to keep up with the commits made to the Joomla! SVN
repository? Well I have the ultimate tool for you: the official
Joomla! commits mailing list. Its full of non stop committing action,
watch every change as it occurs, monitor the change log for entries
-
1.6 backend configuration
Would someone mind fixing the 1.6 configuration screen after a new
install. It's a bit whacked when full error reporting is on (which it
now is by default).
Thanks.
Regards,
Andrew Eddie
-
Question about como_contact router
Hi, all,
I need some help here.
I am working on this issue.
[link]
I believe this issue was caused by router.php within "com_contact",
and possibly happen at other components too.
The "static $items;" within function ContactBuildRoute seems pull out
-
Re: Refactoring global $option
OK global $option to be replaced by JRequest::getCmd(). I think
you're all crazy for not wanting a more specific method, but it sounds
like we'll be using 'option' for several more releases so there's no
need to centralize this logic. ;)
Re: the controllers ( and I'm sorry if I sound like Santa's elf
-
Re: Refactoring global $option
Groovy groovy. For now I'm just going to update the framework, and if
I have time I'll try to tear $option out of other places. Def put it
in the legacy plugin.
tcp
-
Re: Refactoring global $option
I'd just move global $option into what will be the 1.5 legacy mode
plugin (if not already created, Toby, you want to handle that?), and
use JRequest::getCmd('option') where needed.
++
Regards,
Andrew Eddie
2008/10/7 Rob Schley <rob.sch...@community.joomla.o rg>:
-
Re: Refactoring global $option
Hi Toby,
A very good question ! There is the fact what to do with the global
and then there is the question how to deal with the option information
in the request. The option global, as you rightly point out can and
should be removed in 1.6. It can easily be replaced using
JRequest::getCmd. I wouldn't make it part of the router, the router is
|
Newsfeeds