I'd like to get some input from you all on what may be a someone sensitive
topic to some. To put it bluntly JError is a marked man. His time has
come and gone once already, but he was given a stay of execution.
Originally we had JError marked deprecated for removal in the 12.1
release. After some intense conversations we decided to push removal out
to the 13.1 release.
In the meantime several things were marked deprecated for removal in 12.3.
Some of those things were the `JObject::getError()` family of methods.
I've given them a similar extension to the 13.1 release because we need to
figure out how we are going to do this change.
Essentially what we have are a number of classes and methods in the
platform that do things like:
```
if ($expression == false)
{
$this->setError('My error message is foo.');
return false;
}
```
The JTable classes are infamous for this sort of activity. What needs to
happen is that all of those things need to get translated into messages
being queued, exceptions being thrown, etc. I count 162 matches on
`->setError(` in the platform libraries right now. In reality that isn't a
whole lot to deal with, but we need to agree upon the how and we need a few
people to help us get the work done once we've decided upon the how.
I suppose it is not possible to do some magic for b/c purposes and
convert calls to JError into exceptions or messages in the queue? I
don't think fixing this in core will be difficult, but it seems like
it might create major b/c issues. Mark
On Mon, Oct 8, 2012 at 12:02 AM, Louis Landry <louislan...@gmail.com> wrote:
> Hi guys and gals,
> I'd like to get some input from you all on what may be a someone sensitive
> topic to some. To put it bluntly JError is a marked man. His time has come
> and gone once already, but he was given a stay of execution. Originally we
> had JError marked deprecated for removal in the 12.1 release. After some
> intense conversations we decided to push removal out to the 13.1 release.
> In the meantime several things were marked deprecated for removal in 12.3.
> Some of those things were the `JObject::getError()` family of methods. I've
> given them a similar extension to the 13.1 release because we need to figure
> out how we are going to do this change.
> Essentially what we have are a number of classes and methods in the platform
> that do things like:
> ```
> if ($expression == false)
> {
> $this->setError('My error message is foo.');
> return false;
> }
> ```
> The JTable classes are infamous for this sort of activity. What needs to
> happen is that all of those things need to get translated into messages
> being queued, exceptions being thrown, etc. I count 162 matches on
> `->setError(` in the platform libraries right now. In reality that isn't a
> whole lot to deal with, but we need to agree upon the how and we need a few
> people to help us get the work done once we've decided upon the how.
I've been puzzling over those setErrors for a while when I come across them
(and never have been able to get a consensus answer by asking people what
to do with them). Overall I think a lot of the things that should be
exceptions have already started down that path should just finish that
journey by turning into logged messages and leaving it to the application
to add a message if it makes sense. But there are a some places where the
message queue makes sense especially when they are closer to the user.
Is there any news from the PWG that is supposed to be working on the
message queueing? I think consideration of that has to be part of the
discussion.
On Mon, Oct 8, 2012 at 10:58 AM, Mark Dexter <dextercow...@gmail.com> wrote:
> I suppose it is not possible to do some magic for b/c purposes and
> convert calls to JError into exceptions or messages in the queue? I
> don't think fixing this in core will be difficult, but it seems like
> it might create major b/c issues. Mark
> On Mon, Oct 8, 2012 at 12:02 AM, Louis Landry <louislan...@gmail.com>
> wrote:
> > Hi guys and gals,
> > I'd like to get some input from you all on what may be a someone
> sensitive
> > topic to some. To put it bluntly JError is a marked man. His time has
> come
> > and gone once already, but he was given a stay of execution. Originally
> we
> > had JError marked deprecated for removal in the 12.1 release. After some
> > intense conversations we decided to push removal out to the 13.1 release.
> > In the meantime several things were marked deprecated for removal in
> 12.3.
> > Some of those things were the `JObject::getError()` family of methods.
> I've
> > given them a similar extension to the 13.1 release because we need to
> figure
> > out how we are going to do this change.
> > Essentially what we have are a number of classes and methods in the
> platform
> > that do things like:
> > The JTable classes are infamous for this sort of activity. What needs to
> > happen is that all of those things need to get translated into messages
> > being queued, exceptions being thrown, etc. I count 162 matches on
> > `->setError(` in the platform libraries right now. In reality that
> isn't a
> > whole lot to deal with, but we need to agree upon the how and we need a
> few
> > people to help us get the work done once we've decided upon the how.
> I've been puzzling over those setErrors for a while when I come across
> them (and never have been able to get a consensus answer by asking people
> what to do with them). Overall I think a lot of the things that should be
> exceptions have already started down that path should just finish that
> journey by turning into logged messages and leaving it to the application
> to add a message if it makes sense. But there are a some places where the
> message queue makes sense especially when they are closer to the user.
> Is there any news from the PWG that is supposed to be working on the
> message queueing? I think consideration of that has to be part of the
> discussion.
> Elin
> On Mon, Oct 8, 2012 at 10:58 AM, Mark Dexter <dextercow...@gmail.com>wrote:
>> I suppose it is not possible to do some magic for b/c purposes and
>> convert calls to JError into exceptions or messages in the queue? I
>> don't think fixing this in core will be difficult, but it seems like
>> it might create major b/c issues. Mark
>> On Mon, Oct 8, 2012 at 12:02 AM, Louis Landry <louislan...@gmail.com>
>> wrote:
>> > Hi guys and gals,
>> > I'd like to get some input from you all on what may be a someone
>> sensitive
>> > topic to some. To put it bluntly JError is a marked man. His time has
>> come
>> > and gone once already, but he was given a stay of execution.
>> Originally we
>> > had JError marked deprecated for removal in the 12.1 release. After
>> some
>> > intense conversations we decided to push removal out to the 13.1
>> release.
>> > In the meantime several things were marked deprecated for removal in
>> 12.3.
>> > Some of those things were the `JObject::getError()` family of methods.
>> I've
>> > given them a similar extension to the 13.1 release because we need to
>> figure
>> > out how we are going to do this change.
>> > Essentially what we have are a number of classes and methods in the
>> platform
>> > that do things like:
>> > The JTable classes are infamous for this sort of activity. What needs
>> to
>> > happen is that all of those things need to get translated into messages
>> > being queued, exceptions being thrown, etc. I count 162 matches on
>> > `->setError(` in the platform libraries right now. In reality that
>> isn't a
>> > whole lot to deal with, but we need to agree upon the how and we need a
>> few
>> > people to help us get the work done once we've decided upon the how.
>> > So.... how do we want to handle this thing?
>> > - Louis
-- Chris Davenport
Joomla Production Leadership Team
I think we can do all this with minimal backward compatibility
(depending on how you define it), or none at all. The issue boils
down to extension developers writing dual-version 2.5+3.x code. The
main issue is handling exceptions in 3.x and JError in 2.5, which is
exactly the same problem we have here (getting developers to handle
more exceptions).
So, thinking out loud, I think getError method could change to just
return false; getErrors method could change to return an empty array;
and setError could change to throw an exception. Because dual-version
developers already have to cope with exceptions from 3.x, it should
impact minimally. Obviously 3.1 (I expect) developers will have some
slight issues because JError::* disappears but they can make the
appropriate changes now, in 3.0 land, to prepare for that. Anyone that
has an iPhone sees the same sort of things in the App store (Minor
update for iOS6/iPhone 5 compatibility) so it's not an unreasonable
expectation to have of developers.
Regards,
Andrew Eddie
On 9 October 2012 00:58, Mark Dexter <dextercow...@gmail.com> wrote:
> I suppose it is not possible to do some magic for b/c purposes and
> convert calls to JError into exceptions or messages in the queue? I
> don't think fixing this in core will be difficult, but it seems like
> it might create major b/c issues. Mark
> On Mon, Oct 8, 2012 at 12:02 AM, Louis Landry <louislan...@gmail.com> wrote:
>> Hi guys and gals,
>> I'd like to get some input from you all on what may be a someone sensitive
>> topic to some. To put it bluntly JError is a marked man. His time has come
>> and gone once already, but he was given a stay of execution. Originally we
>> had JError marked deprecated for removal in the 12.1 release. After some
>> intense conversations we decided to push removal out to the 13.1 release.
>> In the meantime several things were marked deprecated for removal in 12.3.
>> Some of those things were the `JObject::getError()` family of methods. I've
>> given them a similar extension to the 13.1 release because we need to figure
>> out how we are going to do this change.
>> Essentially what we have are a number of classes and methods in the platform
>> that do things like:
>> ```
>> if ($expression == false)
>> {
>> $this->setError('My error message is foo.');
>> return false;
>> }
>> ```
>> The JTable classes are infamous for this sort of activity. What needs to
>> happen is that all of those things need to get translated into messages
>> being queued, exceptions being thrown, etc. I count 162 matches on
>> `->setError(` in the platform libraries right now. In reality that isn't a
>> whole lot to deal with, but we need to agree upon the how and we need a few
>> people to help us get the work done once we've decided upon the how.
> On 8 October 2012 17:39, Elin Waring <elin....@gmail.com <javascript:>>wrote:
>> I've been puzzling over those setErrors for a while when I come across >> them (and never have been able to get a consensus answer by asking people >> what to do with them). Overall I think a lot of the things that should be >> exceptions have already started down that path should just finish that >> journey by turning into logged messages and leaving it to the application >> to add a message if it makes sense. But there are a some places where the >> message queue makes sense especially when they are closer to the user.
>> Is there any news from the PWG that is supposed to be working on the >> message queueing? I think consideration of that has to be part of the >> discussion.
>> Elin
>> On Mon, Oct 8, 2012 at 10:58 AM, Mark Dexter <dexter...@gmail.com<javascript:> >> > wrote:
>>> I suppose it is not possible to do some magic for b/c purposes and >>> convert calls to JError into exceptions or messages in the queue? I >>> don't think fixing this in core will be difficult, but it seems like >>> it might create major b/c issues. Mark
>>> On Mon, Oct 8, 2012 at 12:02 AM, Louis Landry <louis...@gmail.com<javascript:>> >>> wrote: >>> > Hi guys and gals,
>>> > I'd like to get some input from you all on what may be a someone >>> sensitive >>> > topic to some. To put it bluntly JError is a marked man. His time >>> has come >>> > and gone once already, but he was given a stay of execution. >>> Originally we >>> > had JError marked deprecated for removal in the 12.1 release. After >>> some >>> > intense conversations we decided to push removal out to the 13.1 >>> release.
>>> > In the meantime several things were marked deprecated for removal in >>> 12.3. >>> > Some of those things were the `JObject::getError()` family of methods. >>> I've >>> > given them a similar extension to the 13.1 release because we need to >>> figure >>> > out how we are going to do this change.
>>> > Essentially what we have are a number of classes and methods in the >>> platform >>> > that do things like:
>>> > The JTable classes are infamous for this sort of activity. What needs >>> to >>> > happen is that all of those things need to get translated into messages >>> > being queued, exceptions being thrown, etc. I count 162 matches on >>> > `->setError(` in the platform libraries right now. In reality that >>> isn't a >>> > whole lot to deal with, but we need to agree upon the how and we need >>> a few >>> > people to help us get the work done once we've decided upon the how.
>>> > So.... how do we want to handle this thing?
>>> > - Louis
> -- > Chris Davenport > Joomla Production Leadership Team
