openpsa / createphp Goto Github PK

as a follow-up from #10 and the fact that almost all metadata definition can be omitted, i propose that we add validate methods to the type interfaces that provide a way to warn about autocreated property attribute for propertydefinition resp. rel attribute for collectiondefinition, missing typeof, and any other things that could be relevant.

1.0.0...master :)

Hi there,

When using the Midgard\CreatePHP\MapperDoctrineOrmMapper, with the twig function createphp_attributes() will generate RDFA attributes like:
xmlns:schema="http://schema.org/" typeof="schema:Page" about="Acme\DemoBundle\Entity\Page|id=1"

That's ok, untill you want to save something via CreateJS..

The URL will change the Repository class name in : Acme/DemoBundleEntity/Page.

The fix for this could be in Midgard\CreatePHP\MapperDoctrineOrmMapper after this line:
#73 $class = ltrim($ids[0], '/'); // if we get the / from the url, this breaks the class loader in a funny way.

Putting this line.
#74 $class = str_replace('/', '', $class); // change slashes -> backslashes for the repository class

Is this an OK fix and should I commit it? Or should this problem be solved differently? (I also saw when passing the repository class name like AcmeDemoBundle:Page it also works).

I'm using:
"symfony/framework-standard-edition" 2.3.11

With the following extra bundles:
"symfony-cmf/create-bundle": "1.0.@dev",
"midgard/createphp": "0.9.@dev"

Thanks in advance!

It would be nice if an extending class would inherit the mappings from its base class. Doctrine metadata does that for example.

Hi,

I have implemented a basic silex app using createphp. Im pretty happy so far but I'd like to take it a step further!

I plan to eventually have various kinds of content to edit, like dates, images and other collections.

My current goal is to create a simple gallery, so id like to just have a list of images with an add button which brings up just a upload image interface. I'm currently it's CKeditor for everything.

Any advice welcomed!

Could not find any other place for support requests, is there any?

With this config

        $this->config = array   (
            'workflows' => array(
                //'delete' => 'RISRdfWorkflowDelete'
            ),
            'types' => array(
                'EventVersionsAvailable' => array(
                    'config' => array(
                        'storage' => 'some_db_table',
                    ),
                    'typeof' => 'sioc:Post',
                    'vocabularies' => array(
                        'dcterms' => 'http://purl.org/dc/terms/',
                        'sioc' => 'http://rdfs.org/sioc/ns#'
                    ),
                    'properties' => array(
                        'content' => array(
                            'property' => 'sioc:content'
                        ),
                    ),
                    'children' => array(),
                ),
            )
        );
.......
echo $entity;

gives only one <div about="EventVersionsAvailable" typeof="sioc:Post" xmlns:sioc="http://rdfs.org/sioc/ns#" xmlns:dcterms="http://purl.org/dc/terms/" aria-disabled="false"></div> without the content property. Should properties be declared in children? Probably not. My model does contain public $content;.
Call log:
EventVersionsAvailable::__construct
RISRdfMapper::createSubject: EventVersionsAvailable

Obviously RISRdfMapper::getPropertyValue is never called. Need help.
To clarify: I only have a single EventVersionsAvailable object for simplification so don't be alarmed that my "subject" is only a class name without any ID.

It seems that the latest pull request broke the twig extension:

https://travis-ci.org/symfony-cmf/cmf-sandbox/jobs/3162736/#L1463

The fun thing is that the unit tests still pass, but that's because the twig extension unittests use their own implementation of RdfFactory. I'm not exactly sure why that was done (intuitively, I would say it should be a mock object instead), and I don't have a symfony testbed for this, so @dbu, could you take a look at it if you have some time?

While working with this library I ran into the following fatal error:

Fatal error: Can't inherit abstract function Midgard\CreatePHP\NodeInterface::getChildren() (previously declared abstract in Midgard\CreatePHP\Type\TypeInterface) in ../vendor/midgard/createphp/src/Midgard/CreatePHP/Entity/EntityInterface.php on line 20

commenting out
function getChildren();

in either /NodeInterface or Type/TypeInterface makes things work. I am not sure if this is the preferred way or which one is correct.

Thanks

we are trying to implement collections in the cmf to be able to create content. seems we have a chicken-and-egg problem with createphp: to be able to call the RestService that would understand the json we already need the type. when updating, we get the type from the object model because of the subject. but when creating something new, the subject is a dummy value.

it seems RestService::run expects the parent type in the case of POST (though this is not well documented) and then looks for the right collection child to attach the new document. to be able to do something, we propose to add a method to RestService that will extract the partOf subject from the JSON data so that we can find the right parent type. (we could do this in the client code, but that would mean to know the hairy details of <> around subject and such. PR to come soonish from @adou600.

but eventually, the RestService should accept POST requests without a type instance and look for the @ type and the partOf with the help of the mapper. (or should we continue to inject the parent type?) the logic that the type is defined on the collection will not work for mixed collections. see #23

currently we only provide xml to define the mapping between RDF and the model classes. it would be nice to support annotations and the yml format as well. see the doctrine commons library which could do most of the work for this.

in the cmf, we get duplicate add buttons when rendering collections. i tracked this down to be because of having an about attribute in the collection container even if we are inside the entity. either we have to remove this line: https://github.com/flack/createphp/blob/master/src/Midgard/CreatePHP/Entity/Controller.php#L107 and document that if you want a collection you at least need to render the definition of the containing element - or we need to document that you must render the collection outside of the entity (which seems wrong to me). or we could have a parameter to the collection render telling wheter we are inside an entity or not. but this becomes complicated...

as a side note, i also notice we output way too many namespace declarations because the elements do not know if they are rendered inside the scope of another element or not, when rendering the elements separately.

Right now, the twig unit tests use their private implementation of rdftypefactory, which means that there is a risk that they are out of sync with the main library code so that some errors cannot be detected (see #35). This should be changed so that the tests use the real factory instead of the private implementation

#109 $type = $this->typeFactory->getTypeByClass($model);

should be
#109 $type = $this->typeFactory->getTypeByObject($model);

??

doing the refactoring the rdf type definition loading. i am a bit confused by the laxness of the definitions by the ArrayLoader. it seems we can even create a type without the typeof information.

we should be clear what are the required configurations and what are optional. ok, writing things down there is not much that needs to be optional.

for the type, i think minimum we need to know:

• class name this type represents
• typeof (if this is optional, what do we do? i think createjs needs it to see the item)

for properties, we need

• identifier name

for collections we need

• identifier
• rel is generated from identifier if not available
• i think we should drop the type reference here and give the collection the metadata loading so it can load the right type when binding with data

does that make sense?

Create.js now able to utilize VIE's type registry for some features like smarter collection handling. This will also be the base used for client-side validation bergie/create#52 and metadata editing bergie/create#59

For all this, it would be good if CreatePHP had the schema export capability in place. The schema export can either provide all content types and their attributes in a single big JSON file, or in multiple files depending on performance constraints.

The Schema.org schemas are an example of this format: http://schema.rdfs.org/all.json

Hi,

it appears to me that mapping a type and using the xmlns:<prefix>="<url>" definition creates the corresponding xmlns: html attribute for the element you chose to be your wrapper, which, as far as i understand and the w3c validator tells me, isn't allowed in html5, or at least deprecated, resulting in a 'Attribute xmlns: not allowed here' validation error at w3c, even though it is still processed.

See: http://www.w3.org/TR/rdfa-in-html/#backwards-compatibility

Rather than using xmlns:<prefix>="<url>" in html5 it seems to be advised to use prefix="<prefix>: <url>". or the vocab=<url> attribute for definition of the namespace without a prefix. The definition of both attributes in the mapping/type though will be ignored by the RdfDriverXml::loadType() function (and is probably semantically incorrect?)

An easy fix would probably be to translate the namespace definition in the mapping to the corresponding prefix attribute but i'm not really sure if this is good as it's only the html5+rdfa 1.1 spec that would be served by that?

This issue is a followup from https://groups.google.com/forum/#!topic/symfony-cmf-users/5TCfp2Xzups

Thanks for the read

Having manually output

        <div class="article" about="EventVersionsAvailable">
            <div property="content">
                Some content
            </div>
        </div>

the Create.js editor is working. Saving is not working correctly though. Call log:
RISRdfMapper::getBySubject(EventVersionsAvailable)
EventVersionsAvailable::__construct
RISRdfMapper::createSubject: EventVersionsAvailable
RISRdfMapper::store
EventVersionsAvailable::store
RISRdfMapper::createSubject: EventVersionsAvailable

Again, though RISRdfMapper::store is called, there is no call to RISRdfMapper::setPropertyValue anywhere so EventVersionsAvailable::store doesn't store anything. Please help, will provide any additional information if required.

hi flack,

do you have strong opinions on open source licenses? would it be a problem to switch this project to MIT or Apache? the problem with lgpl is that if for example i write my own type and entity implementation for some specific customer scenario, i would always be forced by the license to opensource them. even the symfony bundle for it could be debatable, because it is not a pure consumer of the library but also extends the library itself...

btw, create.js is MIT licensed, and one of the reasons why @bergie created hallo is that aloha is GPL...

cheers,david

we should do some error handling (or define exceptions to be thrown) so that the controller can tell create.js if something went wrong. creation of entity failed, update failed, no permissions, ...

The 0.8.0 release is already six months old and there have been quite a few changes since, so I guess it would be a good time to start thinking about a new release.

This ticket is basically a request for comments from various stakeholders, @dbu, @adou600 and anyone else who might be interested: In your opinion, which tickets should be addressed before a new release, and how do we want to call it, 0.8.1 or 0.9.0?

From the announcement:

Create.js now has some new collection handling features, like supporting custom templates and multiple types of items in same collection: http://bergie.iki.fi/blog/create-collections/

See and example in https://github.com/bergie/create/blob/master/examples/example-withtype.html

i think it is a bad idea that the type loading mechanism returns null when a type is not found. in the end most code will not be able to continue when a type/entity is null, so userland code must check the return value or risk fatal errors when calling methods on "null". with exceptions, users can ignore the issue and get uncaught exceptions, or catch them and handle if it makes sense for them.

RdfTypeFactory does this because i modelled it after the Manager, but i think we should change both to throw exceptions when there is no type.

the metadata drivers (i.e. xml driver) should read the "name" for a type from the metadata, instead of determining it from the class. this means that for every request, we will need to know the full list of mapped data - meaning we should start to cache compiled metadata for performance reason.

see AbstractRdfDriver::objectToName

ATM, the Twig extension can only render a node's attributes and content. It would be good if it could also render the opening and closing tags or the entire node at once. This would allow users to address the problem with duplicate about attributes mentioned here: #29 (comment)

@dbu: I can add the necessary code to CreatephpExtension, but I still don't have a symfony2 testbed (maybe I'll do that over the holidays...), so any testing would have to be done by you or @adou600

it would be great to be able to use more than one mapper at the same time, so that i can edit objects coming from different sources. this could be different databases, but also different types like phpcr, orm and symfony translation strings (see liip/LiipTranslationBundle#21)

i guess the best approach would be to have a ChainMapper that decides by type name which of the mappers to use. we would need to make sure that when a request comes in from the frontend we also know the type.

if you would want to use several mappers of the same class for different databases, it would mean that each type may only come from one database, never be in one or another database. (e.g. doctrine orm you would make sure that each mapper contains a different subset of your orm mapped entities). the ChainMapper could support the mixed approach and cycle through all mappers knowing about a type name, but then when storing a new entity it does not know with which of the mappers to store it.

I can't add and upload images

follow-up of #27

we should have the hierarchy in the entities and make sure we only render namespaces and the collection about attribute if they are not rendered in the outside hierarchy.

this should even work when using the renderAttributes and renderContent and manually rendering properties and collections of entities.

for use with composer, it would make a lot of sense to tag a version as soon as things have settled. that way other code can depend on a reliable version and does not accidentally update all the time by referencing dev-master.

http://packagist.org/about say to use semantic versioning. i suggest we tag something like 1.0.0-beta1