Content Type Component
23 views
Skip to first unread message
Daniel Leech
Jun 24, 2016, 6:03:15 PM6/24/16
to symfony-...@googlegroups.com
Hello all,
I think one thing that is missing in the CMF stack is a content type
component.
All CMS systems that I know of have a concept of a content type or
similar. Content types combine storage, forms and display
responsibilities for a specific type of content (e.g. article, blog
post, event, person).
These are different from entities/documents in that they are composed of
both scalar and "complex" types. Complex types are composed of many
scalar and potentially other complex fields.
They do this by defining a metadata object describing the fields of the
content. Each field is of a specific type and defines how its data
should be stored, how its form should be displayed and how its content
should be rendered.
About a month back I sketched out some documentation:
https://github.com/dantleech/cmf-content-type/blob/master/docs/introduction.rst
The most challenging bit will be storage - for this I envisage
generating a schema for the storage driver (PHPCR-ODM, ORM), and perhaps
generating the related entities in a cached location.
To take a bolt inspired example:
content_type_1:
fields:
name:
type: text
avatar:
type: image
height: 100
width: 100
rotation: 90
path: /path/to/image.jpg
In this case "name" would be mapped to a scalar field in the
content-entity (PHPCR/ORM) whilst avatar would be mapped as an object
(e.g. "value obect" in ORM - the fields of which will be composed into
the objects table). This would mean all the complex data would be stored
in a single row with the ORM,
As for the other problems, forms are solved entirely by the Symfony Form
component, whilst the "view" (frontend rendering / data) would be a
variation on the Form views pattern.
Cheers,
Dan
I think one thing that is missing in the CMF stack is a content type
component.
All CMS systems that I know of have a concept of a content type or
similar. Content types combine storage, forms and display
responsibilities for a specific type of content (e.g. article, blog
post, event, person).
These are different from entities/documents in that they are composed of
both scalar and "complex" types. Complex types are composed of many
scalar and potentially other complex fields.
They do this by defining a metadata object describing the fields of the
content. Each field is of a specific type and defines how its data
should be stored, how its form should be displayed and how its content
should be rendered.
About a month back I sketched out some documentation:
https://github.com/dantleech/cmf-content-type/blob/master/docs/introduction.rst
The most challenging bit will be storage - for this I envisage
generating a schema for the storage driver (PHPCR-ODM, ORM), and perhaps
generating the related entities in a cached location.
To take a bolt inspired example:
content_type_1:
fields:
name:
type: text
avatar:
type: image
height: 100
width: 100
rotation: 90
path: /path/to/image.jpg
In this case "name" would be mapped to a scalar field in the
content-entity (PHPCR/ORM) whilst avatar would be mapped as an object
(e.g. "value obect" in ORM - the fields of which will be composed into
the objects table). This would mean all the complex data would be stored
in a single row with the ORM,
As for the other problems, forms are solved entirely by the Symfony Form
component, whilst the "view" (frontend rendering / data) would be a
variation on the Form views pattern.
Cheers,
Dan
Lukas Kahwe Smith
Jun 28, 2016, 5:38:58 AM6/28/16
to symfony-...@googlegroups.com
I guess if we do define such a format, then we can of course try to generate it from ODM/ORM mappings as a way to get started .. or as a fallback when there is no mapping.
regards,
Lukas Kahwe Smith
sm...@pooteeweet.org
Daniel Leech
Jun 28, 2016, 5:48:36 AM6/28/16
to symfony-...@googlegroups.com
content types. So there would be an ImageTypeEmbeddable (f.e.) with the
fields "height, width, rotation" etc.
So its actually a way to avoid using PHPCR here.
[1] http://doctrine-orm.readthedocs.io/projects/doctrine-orm/en/latest/tutorials/embeddables.html
> I guess if we do define such a format, then we can of course try to generate it from ODM/ORM mappings as a way to get started .. or as a fallback when there is no mapping.
would generate the mapping for the ORM/ODM. The entities could either
then be hidden away in a temporary directory or be manually created (or
generated) by/for the user.
> --
> You received this message because you are subscribed to the Google Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Wouter de Jong
Jul 9, 2016, 6:45:38 AM7/9/16
to Daniel Leech
I like this idea a lot. It's like the NodeType library of Neos, which I like a lot.
This would however be the first library in the CMF that implements front-end stuff,
almost heading towards a fully functioning CMS like Sulu. If that's what we want, this
is the missing library indeed.
Daniel Leech
Jul 9, 2016, 1:11:36 PM7/9/16
to symfony-...@googlegroups.com
I've created the basic architecture (minus frontend view). This
comprises of Metadata, Fields and FormBuilder.
I took the liberty of transfering it to the CMF repository and updated
the "introduction" (we can move these to offical docs in future):
https://github.com/symfony-cmf/cmf-content-type/blob/master/docs/introduction.rst
Next task will be adding the (frontend) view builder (I think it will be
very similar to the Symfony Form "view", but for the frontend).
Then we need to add storage strategies - the easiest will be JSON/PHP
serializing the complex data, which will work with any underlying
storage driver. In the future we can add support for Doctrine
Embeddables / PHPCR child objects.
This is will hopefully be a rather simple component / bundle (at least
initially), but I think will be very valuable :)
p.s. the code generation I hinted at initially won't be needed I think.
User just has to create their entities. We can even support
annotations:
class NewsPage
{
/**
* @CMFContent\Field('text')
*/
property $title;
/**
* @CMFContent\Field('resource_list', {
* options = {
* repository = "news"
* glob = "symfony-cmf/*"
* }
* )
*/
property $news;
> [4]http://doctrine-orm.readthedocs.io/projects/doctrine-orm/en/latest/tutorials/embeddables.html
> > For more options, visit [7]https://groups.google.com/d/optout.
> For more options, visit [9]https://groups.google.com/d/optout.
> For more options, visit [11]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:dan...@dantleech.com
> 2. mailto:dan...@dantleech.com
> 3. https://github.com/dantleech/cmf-content-type/blob/master/docs/introduction.rst
> 4. http://doctrine-orm.readthedocs.io/projects/doctrine-orm/en/latest/tutorials/embeddables.html
> 5. mailto:sm...@pooteeweet.org
> 6. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 7. https://groups.google.com/d/optout
> 8. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 9. https://groups.google.com/d/optout
> 10. mailto:symfony-cmf-de...@googlegroups.com
> 11. https://groups.google.com/d/optout
comprises of Metadata, Fields and FormBuilder.
I took the liberty of transfering it to the CMF repository and updated
the "introduction" (we can move these to offical docs in future):
https://github.com/symfony-cmf/cmf-content-type/blob/master/docs/introduction.rst
Next task will be adding the (frontend) view builder (I think it will be
very similar to the Symfony Form "view", but for the frontend).
Then we need to add storage strategies - the easiest will be JSON/PHP
serializing the complex data, which will work with any underlying
storage driver. In the future we can add support for Doctrine
Embeddables / PHPCR child objects.
This is will hopefully be a rather simple component / bundle (at least
initially), but I think will be very valuable :)
p.s. the code generation I hinted at initially won't be needed I think.
User just has to create their entities. We can even support
annotations:
class NewsPage
{
/**
* @CMFContent\Field('text')
*/
property $title;
/**
* @CMFContent\Field('resource_list', {
* options = {
* repository = "news"
* glob = "symfony-cmf/*"
* }
* )
*/
property $news;
}
On Sat, Jul 09, 2016 at 12:45:35PM +0200, Wouter de Jong wrote:
> I like this idea a lot. It's like the NodeType library of Neos, which I
> like a lot.
> This would however be the first library in the CMF that implements
> front-end stuff,
> almost heading towards a fully functioning CMS like Sulu. If that's what
> we want, this
> is the missing library indeed.
On Sat, Jul 09, 2016 at 12:45:35PM +0200, Wouter de Jong wrote:
> I like this idea a lot. It's like the NodeType library of Neos, which I
> like a lot.
> This would however be the first library in the CMF that implements
> front-end stuff,
> almost heading towards a fully functioning CMS like Sulu. If that's what
> we want, this
> is the missing library indeed.
> 2016-06-28 11:48 GMT+02:00 Daniel Leech <[1]dan...@dantleech.com>:
>
> On Tue, Jun 28, 2016 at 11:38:54AM +0200, Lukas Kahwe Smith wrote:
> >
> > > On 25 Jun 2016, at 00:03, Daniel Leech <[2]dan...@dantleech.com>
>
> On Tue, Jun 28, 2016 at 11:38:54AM +0200, Lukas Kahwe Smith wrote:
> >
> wrote:
> > >
> > > Hello all,
> > >
> > > I think one thing that is missing in the CMF stack is a content type
> > > component.
> > >
> > > All CMS systems that I know of have a concept of a content type or
> > > similar. Content types combine storage, forms and display
> > > responsibilities for a specific type of content (e.g. article, blog
> > > post, event, person).
> > >
> > > These are different from entities/documents in that they are
> composed of
> > > both scalar and "complex" types. Complex types are composed of many
> > > scalar and potentially other complex fields.
> > >
> > > They do this by defining a metadata object describing the fields of
> the
> > > content. Each field is of a specific type and defines how its data
> > > should be stored, how its form should be displayed and how its
> content
> > > should be rendered.
> > >
> > > About a month back I sketched out some documentation:
> > >
> > >
> [3]https://github.com/dantleech/cmf-content-type/blob/master/docs/introduction.rst
> > >
> > > Hello all,
> > >
> > > I think one thing that is missing in the CMF stack is a content type
> > > component.
> > >
> > > All CMS systems that I know of have a concept of a content type or
> > > similar. Content types combine storage, forms and display
> > > responsibilities for a specific type of content (e.g. article, blog
> > > post, event, person).
> > >
> > > These are different from entities/documents in that they are
> composed of
> > > both scalar and "complex" types. Complex types are composed of many
> > > scalar and potentially other complex fields.
> > >
> > > They do this by defining a metadata object describing the fields of
> the
> > > content. Each field is of a specific type and defines how its data
> > > should be stored, how its form should be displayed and how its
> content
> > > should be rendered.
> > >
> > > About a month back I sketched out some documentation:
> > >
> > >
> > I guess if we do define such a format, then we can of course try to
> generate it from ODM/ORM mappings as a way to get started .. or as a
> fallback when there is no mapping.
>
> It would actually work the otherway round - the content type definition
> would generate the mapping for the ORM/ODM. The entities could either
> then be hidden away in a temporary directory or be manually created (or
> generated) by/for the user.
> >
> > regards,
> > Lukas Kahwe Smith
> > [5]sm...@pooteeweet.org
> generate it from ODM/ORM mappings as a way to get started .. or as a
> fallback when there is no mapping.
>
> It would actually work the otherway round - the content type definition
> would generate the mapping for the ORM/ODM. The entities could either
> then be hidden away in a temporary directory or be manually created (or
> generated) by/for the user.
> >
> > regards,
> > Lukas Kahwe Smith
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to [6]symfony-cmf-de...@googlegroups.com.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > For more options, visit [7]https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [8]symfony-cmf-de...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send
> For more options, visit [9]https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [10]symfony-cmf-de...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups
> "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> For more options, visit [11]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:dan...@dantleech.com
> 2. mailto:dan...@dantleech.com
> 3. https://github.com/dantleech/cmf-content-type/blob/master/docs/introduction.rst
> 4. http://doctrine-orm.readthedocs.io/projects/doctrine-orm/en/latest/tutorials/embeddables.html
> 5. mailto:sm...@pooteeweet.org
> 6. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 7. https://groups.google.com/d/optout
> 8. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 9. https://groups.google.com/d/optout
> 10. mailto:symfony-cmf-de...@googlegroups.com
> 11. https://groups.google.com/d/optout
Daniel Leech
Jul 10, 2016, 8:08:39 AM7/10/16
to symfony-...@googlegroups.com
Had a look at storage metadata generation today, decided not to
implement it, wrote it up here:
https://github.com/symfony-cmf/cmf-content-type/issues/1
> To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
implement it, wrote it up here:
https://github.com/symfony-cmf/cmf-content-type/issues/1
> For more options, visit https://groups.google.com/d/optout.
Daniel Leech
Jul 12, 2016, 4:44:54 AM7/12/16
to symfony-...@googlegroups.com
I have created a bundle and added the Core team, so those of you in that
group are probably getting notifications.
Hope I havn't been too forward in creating these repositories without
prior consent here (I should have asked). If anybody is unsure about
what this component/bundle will do or what benefits it will have let me
know. Would be great to get input/collaboration on it.
Will now stop posting to this thread unless to answer any replies.
group are probably getting notifications.
Hope I havn't been too forward in creating these repositories without
prior consent here (I should have asked). If anybody is unsure about
what this component/bundle will do or what benefits it will have let me
know. Would be great to get input/collaboration on it.
Will now stop posting to this thread unless to answer any replies.
David Buchmann
Jul 12, 2016, 5:04:17 AM7/12/16
to symfony-...@googlegroups.com
hi dan,
imo its ok you added this. it sounds really cool.
i am generally reluctant of creating new components and feel like we
rather should officially stop and abandon all but the most important
ones (as discussed previously and partially done). my fear is that we
end up with a lot of never really finished or outdated and barely
maintained things that have some users that are unhappy about not
getting updates...
but those are two conflicting things: do cool stuff, and preserve a
working environment. and i see that only preserving is not interesting
enough in the long run, so we should keep doing cool new stuff too.
cheers,david
imo its ok you added this. it sounds really cool.
i am generally reluctant of creating new components and feel like we
rather should officially stop and abandon all but the most important
ones (as discussed previously and partially done). my fear is that we
end up with a lot of never really finished or outdated and barely
maintained things that have some users that are unhappy about not
getting updates...
but those are two conflicting things: do cool stuff, and preserve a
working environment. and i see that only preserving is not interesting
enough in the long run, so we should keep doing cool new stuff too.
cheers,david
gmx Privat
Jul 12, 2016, 6:02:38 AM7/12/16
to symfony-...@googlegroups.com
:+1:
Like your idea and the component. But we should find a way to handle all repos with currently only 4 persons. I think i will Open a new Thread here to talk a little bit about a way to push our public image(some call it marketing) to get contributors and (visible) users.
Max
Like your idea and the component. But we should find a way to handle all repos with currently only 4 persons. I think i will Open a new Thread here to talk a little bit about a way to push our public image(some call it marketing) to get contributors and (visible) users.
Max
Daniel Leech
Jul 12, 2016, 6:40:13 AM7/12/16
to symfony-...@googlegroups.com
Well -- I am doing this with a practical aim in mind :)
I want to be able to create websites for clients using the CMF. This
component will provide a foundation for building content types,
containing not only scalar fields, but things such as image/image lists,
video, document management, markup, geolocation, content links.
Whats more, these types could be shared between implementations - f.e.
I see no reason why Bolt CMS could not use this library directly (I
havn't asked them, but the architecture would be a perfect fit).
Other potential beneficieries I can think of could include Sonata,
Sylius and Sulu CMS, in each case the content types *could be*
interoperable.
Combined with the resource stack, I think this could be not only cool,
but really enabling, and if adopted by other projects, a great way to
inject more life into the community here.
There seems to be f.e. alot of interest in adding CMS capabilities to
Sylius.
I am working (slowly) on a Sylius-based demo application at the moment
which should demonstrate better than I can explain how this all fits
together :)
I want to be able to create websites for clients using the CMF. This
component will provide a foundation for building content types,
containing not only scalar fields, but things such as image/image lists,
video, document management, markup, geolocation, content links.
Whats more, these types could be shared between implementations - f.e.
I see no reason why Bolt CMS could not use this library directly (I
havn't asked them, but the architecture would be a perfect fit).
Other potential beneficieries I can think of could include Sonata,
Sylius and Sulu CMS, in each case the content types *could be*
interoperable.
Combined with the resource stack, I think this could be not only cool,
but really enabling, and if adopted by other projects, a great way to
inject more life into the community here.
There seems to be f.e. alot of interest in adding CMS capabilities to
Sylius.
I am working (slowly) on a Sylius-based demo application at the moment
which should demonstrate better than I can explain how this all fits
together :)
Reply all
Reply to author
Forward
0 new messages