Received: by 10.204.151.213 with SMTP id d21mr1678029bkw.0.1341789968582;
        Sun, 08 Jul 2012 16:26:08 -0700 (PDT)
X-BeenThere: joomla-dev-platform@googlegroups.com
Received: by 10.204.4.74 with SMTP id 10ls6903148bkq.0.gmail; Sun, 08 Jul 2012
 16:26:06 -0700 (PDT)
Received: by 10.204.129.81 with SMTP id n17mr3796290bks.3.1341789966894;
        Sun, 08 Jul 2012 16:26:06 -0700 (PDT)
Received: by 10.204.129.81 with SMTP id n17mr3796289bks.3.1341789966878;
        Sun, 08 Jul 2012 16:26:06 -0700 (PDT)
Return-Path: <dextercow...@gmail.com>
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181])
        by gmr-mx.google.com with ESMTPS id p5si16112414bks.1.2012.07.08.16.26.06
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sun, 08 Jul 2012 16:26:06 -0700 (PDT)
Received-SPF: pass (google.com: domain of dextercow...@gmail.com designates 209.85.217.181 as permitted sender) client-ip=209.85.217.181;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of dextercow...@gmail.com designates 209.85.217.181 as permitted sender) smtp.mail=dextercow...@gmail.com; dkim=pass header...@gmail.com
Received: by mail-lb0-f181.google.com with SMTP id gk8so3702471lbb.26
        for <joomla-dev-platform@googlegroups.com>; Sun, 08 Jul 2012 16:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        bh=Spgo1fSdZhBk8sGf83QVB22K1rhx/xVvxP2zMxS1Odw=;
        b=Zkmi3vjcUFlOcVfuye/z7Z15NVaBOL9RVxMv8BMgmge8Z+6W+AwKfCD4cCTLJ0mrwO
         BTptwlMqkEs5upiQJTtjlSxeIwoEG6sCp1bjBeTumNOstPL4cBG/FD7rKOfryBqar/GP
         1OY24wccwU2GCyqzRaGpg5doLvHKNVoV5AMAF0PNBF27LvIz4DOU+wUpHsCFMx5wx+/3
         7t340IDfuPSaecRPp6m39kZVgR/R2IaABkHHsLgMvnoJv61lU0Ign7EjiP6uHKkYa6OS
         HTBNF/9WlnSJTGttF7ue75kKQr7bb9YtRdIjfs4VXt0StI8ykR8zCdm4FE7JOJ2RHePX
         GEow==
MIME-Version: 1.0
Received: by 10.112.102.10 with SMTP id fk10mr16860852lbb.39.1341789966538;
 Sun, 08 Jul 2012 16:26:06 -0700 (PDT)
Received: by 10.112.104.35 with HTTP; Sun, 8 Jul 2012 16:26:06 -0700 (PDT)
In-Reply-To: <f05bdaa1-f128-4d0e-bde5-0610ac722bdc@googlegroups.com>
References: <eac98e05-52b6-4837-93f2-ae4e5d9936a7@googlegroups.com>
	<9290B896-4281-4816-B120-5A2915F11...@rouvenwessling.de>
	<f05bdaa1-f128-4d0e-bde5-0610ac722bdc@googlegroups.com>
Date: Sun, 8 Jul 2012 16:26:06 -0700
Message-ID: <CANdmvYt20qxsjCUk068m4uhWk7f=6AMF6_KjsUGOrGMVoX1...@mail.gmail.com>
Subject: Re: [jplatform] JTableContent
From: Mark Dexter <dextercow...@gmail.com>
To: joomla-dev-platform@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Making an abstract class seems like a good approach to me. Mark

On Sun, Jul 8, 2012 at 8:43 AM, Elin Waring <elin.war...@gmail.com> wrote:
> I would really mend not end ... there are a small number of places that a=
re
> CMS specific (I pointed them all out) and existing platform applications
> could well have replaced those, just to point out another possible issue.
> What you suggest is interesting in that it would make sense not to specif=
y
> the field properties if it weren't for the fact that we have already seen
> the future field properties in JContent.  That said I wouldn't mind makin=
g
> it an abstract class similar to JTableNested (which should be abstract bu=
t
> isn't) and then having  content type tables extend it.  That would be
> forward looking.  I don't mind taking a crack at that if the consensus is
> that it would make sense.
>
> Elin
>
>
> On Sunday, July 8,inconsitent 2012 11:00:00 AM UTC-4, Rouven We=DFling wr=
ote:
>>
>> Hi Elin,
>>
>> On 08.07.2012, at 16:50, Elin Waring wrote:
>>
>> > That said I would like to see JTableContent remove its dependencies on
>> > certain CMS concepts such as the existance of something called com_con=
tent,
>> > something called article,  and of a table called #__categories. We cou=
ld
>> > even make the name of the table override-able, which would be forward
>> > looking anyway.  I think just as has been done elsewhere there are way=
s to
>> > do so without breaking existing applications.
>>
>> JTableContent is pretty specific for com_content as you noted, thus it
>> should move to the CMS. That said if someone were to create a more abstr=
act
>> JTable class that different content items could reuse that would certain=
ly
>> be something worth looking into.
>>
>> Rouven