Rouven,

1) Yes, this is a known issue. The main problem is that the three existing
applications (JApplication, JWeb, and JCli) do not share a common
interface. This is the main reason that I've been pushing
JApplicationInterface. I'm going to try to get that all squared away this
week and submit a pull request so we can deal with all the applications in
a similar way. Not having that, we decided to just use JWeb as the base
point because that would be the most adaptable from the platform
perspective.

2) In our implementation, we usually let the controller interact directly
with content objects for CRUD operations and left the model to fetching
data for views. In a revamped MVC paradigm, this would probably change but
that separation worked pretty well given the state of things.

3) I assume the biggest issue was the foreign keys to jos_users? Sorry
about that, it is something we meant to note somewhere but forgot.

4) I think the content stuff as is (aside from needing to be updated) can
go in independently of any MVC work. That's why we decided to release this
chunk of code the way it is instead of tying it to any MVC work that we've
done independently or that is going on in the larger community.

5) We were going to try to do that last week but just got distracted. I'd
be happy to review any fixes you might have.

Cheers,
Rob

On Mon, Jan 23, 2012 at 3:24 AM, Rouven Weßling <m...@rouvenwessling.de>wrote:

On 23 January 2012 20:45, Elin Waring <elin.war...@gmail.com> wrote:

Well, I think it just raises the point that language is thought of in
many different ways.

There is nothing stopping an application from adding the field to the
base table.  JDatabaseObject will work it out.

I would expect that if you need a default language you would include it.

I'm sure one could be provided, just needs someone to write it.

Well, we've already established that language can be considered in
several forms, so I think the role for treating those forms rests with
the search "plugin".

You can add the column for your application.  However, I would leave
handling for that column in a derived class, not JContent.

Well, it would be a reasonable assumption that you are probably going
to have other custom fields, so the join table will exist anyway, but
yes, I'd add the column in the extended data for this case (note: you
don't need one table for language, and then another table for custom
fields - the language column would be a "custom field" among zero to
many more).

Again, you are likely to have a great deal of extended data so there
is no additional overhead in having the language field in the join
table.

The solution I gave to you covers a one-to-one or a one-to-many (aka
ML) situation.  To be perfectly clear on the answer to your question:
I'd use a custom language field (it just happens to also cover ML as
well) *but* a custom application can still do whatever it likes to the
base jos_content table and then define it's own handling in a custom
class (there is a lot of scope to override with custom classes, see
JContentFactory).

Regards,
Andrew Eddie

So you're anticipating there being a set of several fundamentally different
architectural solutions to language aware content management, and I'm
thinking about search, meta data, and mark up.

I thought this from W3C was interesting for the part I'm thinking about

Specifying the language of content is useful for a wide number of
applications, from linguistically-sensitive searching to applying
language-specific display properties. In some cases the potential
applications for language information are still waiting for implementations
to catch up, whereas in others, such as detection of language by voice
browsers, it is a necessity today. On the other hand, adding markup for
language information to content is something that can and should be done
today. Without it, it will not be possible to take advantage of any future
developments.

Elin

There could be fundamentally different approaches but I haven't
thought about it much beyond what I've already mentioned.  As Sam has
already pointed out, it hasn't been a mandate to provide that feature
at this stage, hence it's absence.  You are most welcome to work on it
though.

Regards,
Andrew Eddie

On 24 January 2012 11:35, Elin Waring <elin.war...@gmail.com> wrote:

I know we're still talking about the architecture but I think I may have found a bug but I'm not entirely sure.

If I have a type that uses a second table to store extended fields it doesn't get deleted when I call JConent::delete(). I suspect this is a bug.

I also got a more general question - how do I get the id of a type?
Intuitively I'd have said JContentFactory::getType() with the type name as an argument would get me an object from which I could read the id. However this just loads the class (if not a special one is created just JContent) with no data populated.

My next guess was to try JFactoryHelper::getTypes() which returns an array of all type objects (this time populated) but the id is hidden away in a protected property.

Best regards
Rouven

On 25 January 2012 13:08, Rouven Weßling <m...@rouvenwessling.de> wrote:

You need to have an FK restraint on the content_id and have it
cascade.  That way the database does all the cleanup and you don't
need to code it explicitly.

We generally only have to work with the alias of the type.  What are
you trying to do?

Regards,
Andrew Eddie

On 25.01.2012, at 04:22, Andrew Eddie wrote:

That's where I'm being punished for knowing next to nil about SQL. Will try it out.

As a test bed I'm trying to change com_content to use JContent. I'm using a direct access to the database to fetch the data for the list view. Now if I add another content type they would all be listed (set aside that the innerjoin wouldn't work, let's assume to content types that only use the content table) but I only want those of one content type.

Thanks for your help
Rouven

Ok. Hang off on the list views for now.  We are still working out a
better system for that ourselves.

Regards,
Andrew Eddie

On 25 January 2012 13:31, Rouven Weßling <m...@rouvenwessling.de> wrote:

Rouven,

You can access any of the properties in the JContentType object using the
magic __get(), $type->type_id is the thing you're looking for. If you have
a content object loaded, you can use $content->type->type_id

Just thinking conceptually, are we thinking of everything that renders as a
"page"  in a browser as content?  I think that makes sense and potentially
kind of eliminates some of the difficult-to-get-your-head-around ways (e.g.
seeing not being part of doing in one application but s being part of it
-i.e. core.manage being essentially a seeing permission--in another
application) we have been thinking about ACL implementation for the past
few years.  (Yes I get that we may not end up with two applications running
side by side, but let's just say we did.)

One question I had about the handling of root users is whether any thought
has been given to the other concept that is related to but is disruptive of
the rest of the permissions system which is the concept of "own" e.g.
edit.own, edit.state.own, delete.own, even create.own really if you think
about it.   I mean it works to the extent it is implemented but it breaks
the elegance and rules of the rest of the system (there's no way it makes
sense in a system with strict, default to deny inheritance everywhere else
to suddenly say inside a locked area oh but never mind it's fine to do
whatever you want here. I would think that at scale and with social that
the issue of what really is owned by the user would be really important and
I wonder if you have thought about it? (Not saying I want anything done
about it, just interested in if it has come up at all.)

Elin

Hi,

I decided that I wanted to understand the UCM better so I started playing
around with building some pages using JContent and working with the sample
data from the CMS. Obviously this is pretty crude (there are a bunch of
things that are hard coded that shouldn't be and it's not using MVC at
all), but it is a functioning set of pages and if you are trying to get
your head around the concepts it may help to take a look.

http://ucm.cloudaccess.net/platform/examples/web/content/index.php

https://github.com/elinw/Content--Play
If you want the code.

I am reasonably positive that this doesn't match what was expected by
Louis, Rob et al.,  but I guess when you have a platform that's kind of how
it goes. You get people doing the unexpected.  It definitely is very
empowering in that way. So for example there didn't seem to be a rule that
said each type had to have a separate table just that each type had to have
a table, so I created some new types that use the same tables as others.
(You'll see this in the photo gallery where I  took a category and made it
a gallery type and then took the articles the images were in and made them
type=image instead of type=article).

Overall I found it easy to work with especially when I actually read the
documentation. There are a few things I'd like to see handled better (there
are way too many fatal errors coming out of getting an empty result from a
query--a mistyped URL should not be generating a fatal error and we need a
way to handle making lists based on fields beside content_id and type. As I
said previously I think that language and meta data have a place in the
core content table) but overall I'm really pleased with how easy it is,
even getting the parameters out of the old data is easier than it is now.

I'm not sure what the deal is with process, but I haven't seen anyone
arguing against merging these libraries. Totally separate from the CMS
schedule I'd like to see that happen soon because I think they are going to
create an explosion in people building platform applications for specific
purposes.  

Elin

So about the media field ... I notice that the documentation specifies that
it is JSON and that's great because application X uses JSON to store a
field of images it as does the application that I have been working on. I
think it's pretty useful but it led me to a couple of questions. First, do
we just assume that the application is going to the decoding of that? Or
would the library be aware of it the way it is for config?
Also do you have some general thinking about best practices for using JSON
in JContent? For example, it might make sense to assume that you  store
some or all of meta data in JSON. I know it's not in the core table at the
moment though it's hard for me to imagine an argument for web content best
practices that doesn't include some meta data.

Elin

Just a short reminder:

While JSON is great, JSON should only be used for field contents that
cannot be searchable in database queries. ;-)

Beat
http://www.joomlapolis.com/

On Feb 10, 10:55 pm, Elin Waring <elin.war...@gmail.com> wrote:

I have a question about the config field.
Is the idea here that this would store settings that relate to the common
fields (such as show_title, show_media, show_body, allow_like and so on?
And in that case if you were explaining how to use ucm in development,
would you say that, although it would not be required, often there would be
a second config field that would set the options for fields in the
secondary table?

Elin

Yes, the config field will be used to store various configuration
attributes (whatever they may be).

I think there should only be one config field if they are being used for
(more or less) the same purpose. The fields are in different tables because
that is what the structure requires, the config field has no structural
requirements to split the fields. So, no, there should only be one config
field in my opinion.

Cheers,
Rob

That's what I was thinking originally and I made my content table with
config field structure that was type dependent,  but then when I went to
make the forms I realized that if  content.xml holds the config field then
it's going to have to be the same for all types or at least that's how I
read it. On the other hand maybe the config field should just always be in
type.xml so that they are always type specific, but that is going to make a
lot of redundant xml since a lot of config options will be the same
(show_title, show_body etc). I don't see a structural reason why the
division between primary and secondary table has to match the division
between primary and secondary xml files, when they are in use they are like
one big table and one big form. Is that right?

Elin

The forms support extending/overriding with extra fields just like the
content objects. We use a generic content.xml and then a type specific xml
file if necessary.

So what would make sense to me based on what you are saying is if there is
a common field called config in content.xml but that could be replaced if
the type.xml wanted to override it, but the loadFile for type.xml has the
replace flag set to false so if I understand it correctly JForm is actually
going to ignore the second field with the same name?

https://github.com/eBaySF/joomla-platform/blob/content/libraries/joom...
e
https://github.com/eBaySF/joomla-platform/blob/content/libraries/joom...

Maybe it would make sense to default reset to true so, for example, a field
could be made required or have a different
filter for different types and also for the case I'm interested at the
moment in you could override the config.

I guess I should also change my original question to: Would a type often
have a field called say config_type that would contain a second group of
configuration fields that are specific to the type.

Elin

Actually I think I'm changing my mind on the replace issue, I think it will
be more flexible on a practical level not to replace (not only but partly
because of the issue below), I think it will probably i but I want to raise
another issue.

The JContent package includes an sql file with a number of tables with
user_id as a key and the user_id in the sql file is specified as var(10)
unsigned. This is actually standard in CMS data tables, but those tables do
not currently use those IDs as foreign keys the way JContent does.
 CONSTRAINT `#__content_ibfk_2` FOREIGN KEY (`modified_user_id`) REFERENCES
`#__users` (`id`) ON DELETE SET NULL ON UPDATE CASCADE,
  CONSTRAINT `#__content_ibfk_3` FOREIGN KEY (`checked_out_user_id`)
REFERENCES `#__users` (`id`) ON DELETE SET NULL ON UPDATE CASCADE,
  CONSTRAINT `#__content_ibfk_4` FOREIGN KEY (`created_user_id`) REFERENCES
`#__users` (`id`) ON UPDATE CASCADE

This actually means that if you have a user table created by any prior
verison of the CMS the SQL can't really be imported at least   in MySQL
because you will get an error 150.  This is the issue that Rouven and I
discussed in this thread a few weeks ago.
So I think that if that there needs to be some communication between
platform and CMS and maybe the platform team could suggest to the CMS team
to do an alter table but given that it is likely that there are many many
applications/extensions that use the user table and possibly some of them
have built in FKs the time to give some notice on this is, basically, now
since there could be many ripple effects.(You need a content_id field in
the content table too but that's a simpler thing since it doesn't change
something existing).

This makes me wonder what we should do. I really like having the sql in the
package and in this case it is essential precisely because you do need to
have the keys set up and a specific set of fields. Would the idea be to do
similar for other packages? I think it is a good idea. Although it might
cause some pain in the short term I think it will reduce conflicts in the
longer term especially if people are assuming that the CMS joomla.sql file
is going to be definitive, which it clearly is not in this case and I'm
sure won't be in others going forward. Still we could start by using the
ddl in that file as a baseline for the ddls for platform tables . Then
there is also the question of where this should go, in the table package or
in say the user package?

 The other issue is that there are at least 5 tables that those tables or
JContent have dependencies on (user, usergroups, user_usergroup_maps,
session (unless you aren't storing in the database? But I think even if you
use file it still stores in the database), viewlevels.  It seems to me that
this should probably be in the documentation for the package and really for
any package. Does that make sense? Just to have a standard part of the
manual be a list of the tables needed?    And maybe a list of other
dependencies? That's all going to be necessary if people want to start
taking just specific pieces.

Even though I'm raising this in the UCM thread because that's where it
became clear to me that we have a potential problem, I think it is a more
general issue. And i think there is actually a very immediate issue on the
user id that has to be taken care of if this package is going to be merged.

Elin

Another dependency/question I have is about the assets table. It seems to
me that type are assets since they have permissions and only assets have
permissions, right? And so the parent for an item would be the type, and
would type  have a parent of content or would we just skip the component
level?  So if gallery is a type and i have a gallery with content_id of 592
... that would be gallery.592 in my application since I don't have a
concept of component? I haven't really go my mind completely around how the
assets table works outside of the cms. Or if UCM were implemented in the
CMS as say com_content_types it would be com_content_types.gallery.592?

And then if you wanted to implement a nested content type (which is
something Rob mentioned in NYC) and connect gallery to that for purposes of
inheritance of permissions (and maybe state) then you could conceivably
parent to that in the assets table?  If I wanted to make gallery as a type
itself nested from my reading thus far (and admittedly I'm finding new all
the time) I don't see a simple way to use another gallery as the parent
asset.

Related to that, the current api for categories is dependent on the cms
concept of extension but in moving to types we would escape a major
limitation of  that and be able put different types in the same category
because they are all in the com_content_types extension. Is that right?
 Which is totally great. I know it's a cross over question, but this is
really about using the API.

Are we going to do something about the dependency in categories or is
categories going to move to the cms?

Elin

Actually rereading this thread I realized Rob answered most of my question
about assets weeks ago. I just have that table on my mind for other reasons.

Elin

When you have a moment, would someone explain the difference between a
cursory and full permissions check and possible use cases for each? And
also why not all not the can   methods have the option?

Elin

Sure. It is simple really, "full" checks are available for actions that
require checking out the content item. The full check will call the
canCheckout() method to provide the most accurate response. That is why not
all of the can* methods have a full flag, not all of those actions require
checking out the content. For example, canView() does not require checking
out the content.

I'm currently rethinking some of those methods in conjunction with some
other stuff I'm working on. We'll see if they survive the next iteration.

A thought I want to share concerning the UCM. Exploring Seblod CCK, I saw
that *categories and user(group)s are all considered content types* in
there. So, a category can just as easily get extra fields as an article or
a gallery or whatever. As I'm often working with hierarchical data (hence
my interest in ORM, especially Doctrine 2), the possibilities of using
categories as any other content type struck me.

One of the things that bothered me with Joomla (and remains unchanged for
the UCM) is what I call the  "flat structure": a one-on one relationship
between an object and a table-row, with the restriction of the first normal
form imposed by relational databases. A field in an object cannot have
multiple values, let alone multiple (possibly complex) objects. *But*: if I
make a category content type in the UCM, then I can put other objects
"under" that category. For instance: if an article would be derived from a
category content type, then comments can be put under it easily. The same
for orderlines and orders. Here I still see some other advantages of a
"full blown" ORM (like cascading deletes or lazy loading), but I'm just
playing around with some concepts.

One of the things I think about too, is that some properties and behaviour
that are now fixed in UCM's base content class and inherited by the
subtypes, could better be realised by composition. I'm trying to discern
different behaviours that can be used in different situations; like making
a difference between data, meta-data and "containment data" (in my
definition, content = information that is contained and information = data
+ meta-data). Maybe hierarchy is also just a behaviour, that could be added
to a content type.

I waited posting these half-baked thoughts until I had fully worked it out
in code, but now I thought: let's just put it here, for it might be food
for someone else's inspiration too.

I think that ucm lets the developer decide whether there should be
categories and if  they exist what they should be.

Based somewhat on Rob's talk at JDay NYC and also on just how  I think
about content, I've been treating categories as a content type that happens
to have nesting built into its supplemental table.  This makes sense to
me ontologically (a category is a thing in itself--just like a building is
a thing in itself even though it  contains rooms and then things and people
within rooms).  This was a big discussion in the CMS in terms of  whether
the nesting i.e. should there even be such a thing as a category
description or should empty categories ever be allowed to be displayed if
categories are merely empy vessels for nesting or should we have the
ability to configure at the category level.  This view is not wrong at all,
in some ways ... the types concept solves one kind of issue which is that
in the old model webmasters sometimes used categories as kind of a proxy
for type and had all kinds of work arounds to implement that.  Now we can
just say this is a "type" (we don't even need a new supplemental table) and
give it its own layouts, parameters, ACL and so on.

Another thing that UCM potentially lets developers do is separate out the
idea of nested content from the idea of nested sets for issues like ACL.
 In some contexts that's going to make sense, in others maybe not
especially if ownership can be handled nicely (a previous question I asked
that got lost in other discussions).

The whole matter becomes a question of what you do with the supplemental
table for the type, whether it is the only table or it in turn has, for
example, many to one relationships or for that matter goes out to a
different databases ... that's probably one way to approach comments or
multilingual for example, or any time you need that.  It's still really up
to a developer to decide that, and the supplemental table can be really
minimal. I don't see why there would be any inherent limitation on what you
can do once you leave the supplemental table (any more than there is a
limitation to what happens in the supplemental table beyond the limits of a
single record ).  

Those are just some thoughts, there is definitely a lot to think about and
I suspect developers will push UCM in all kinds of interesting and
unexpected ways.

Elin