JTableContent

[Elin Waring]

Hi,

I'm sorry to post two pain in the neck items the same day but I want to raise some concerns about the wisdom of moving JTableContent to the legacy folder as was done recently.

I know from the UCM thread that eventually the idea is that JDatabaseObject will replace the JTable package, but UCM is not even a pull request yet and as far as I know if the pull request were sent today it would not include removal of the JTable package or JTableContent. So as of now I would think that many platform applications for web applications that have content ... would probably be using the content table.  Further,  if and when applications are encouraged to use JContent (assuming it becomes a pull request and that it is accepted) it would seem to me to be highly preferable that those applications be using the old JTableContent which, according to everything I have heard, was the model for setting up the core content table in JContent.  Yes any random table can be declared a content type in JContent and just structurally have many blank fields, but the truth is it is strongly preferable for them to be tracking assets, to have created_by and date and checked out information and so on and to be actually using these fields (because like it or not JContent is going to use them). 

So, to make it short and sweet: A web application pretty often will want to render data from a database and it seems to me that a platform for web applications would want to provide an api for that.  

That said I would like to see JTableContent remove its dependencies on certain CMS concepts such as the existance of something called com_content, something called article,  and of a table called #__categories. We could 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 ways to do so without breaking existing applications.  

Thanks for your patience,

Elin

[Rouven Weßling]

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_content, something called article, and of a table called #__categories. We could 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 ways 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 abstract JTable class that different content items could reuse that would certainly be something worth looking into.

Rouven

[Elin Waring]

I would really mend not end ... there are a small number of places that are 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 specify 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 making it an abstract class similar to JTableNested (which should be abstract but 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

[Mark Dexter]

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