Better tests for Twig extension

[flack]

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

[dbu]

i started working on making the twig test a full functional test that does not mock anything of createphp. this requires the whole phpcr-odm stack to dev, because the only mapper we have atm is the DoctrinePhpcrOdmMapper... but it actually works (and i fixed a couple of errors in the phcpr-odm doc along the way of bootstrapping this in the test).

anyways, now i am stuck on the problem that since the last refactorings, there seems to be no way to have simple collections of just strings, like the tags we have in our sample model. i won't find a solution for that problem tonight, but will try again on friday.

[flack]

Am 14.11.12 21:40, schrieb David Buchmann:

i started working on making the twig test a full functional test that
does not mock anything of createphp. this requires the whole phpcr-odm
stack to dev, because the only mapper we have atm is the
DoctrinePhpcrOdmMapper... but it actually works (and i fixed a couple of
errors in the phcpr-odm doc along the way of bootstrapping this in the
test).

anyways, now i am stuck on the problem that since the last refactorings,
there seems to be no way to have simple collections of just strings,
like the tags we have in our sample model. i won't find a solution for
that problem tonight, but will try again on friday.

yeah, no problem, we're not in a hurry :-)

Anyways, about the mapper: I had this problem, too in some unittests and
made the MockMapper class (which uses a simle array format as "storage
object"). Since mapper is framework-specific and adheres to an
interface, I don't find it so bad that it's fake. If the phpcr thing is
working, that's fine, too, even if it sounds a bit heavy :-)

—
Reply to this email directly or view it on GitHub
#37 (comment).

[dbu]

thanks for the tip, MockMappers seems to be able to do what i need, much nicer than having all of doctrine in the project.

however, i am still unsure what to do. the problem is with things like tags where we neither specify a "type" in the mapping nor are the single tags objects that the type factory could find rdf types for. what would be the right behaviour? should we provide a simple plaintext default type for such cases? its only a problem with collection items that are not themselves again complex types...
and does anybody have a good example of the html tags that are needed to make the createjs tags widget work? http://createjs.org/guide/#tags

@bergie do you happen to have an example of how the tags should look like in html?

[flack]

Am 16.11.12 17:38, schrieb David Buchmann:

thanks for the tip, MockMappers seems to be able to do what i need, much
nicer than having all of doctrine in the project.

however, i am still unsure what to do. the problem is with things like
tags where we neither specify a "type" in the mapping nor are the single
tags objects that the type factory could find rdf types for. what would
be the right behaviour? should we provide a simple plaintext default
type for such cases? its only a problem with collection items that are
not themselves again complex types...

Hm, I don't know how this is supposed to work in Create.js, but ow
exactly does it work on your end? I mean, if tags are not some form of
staorage entity, I imagine they must be something like a property of
another object, right? So like f.x. a comma-separated string that gets
saved in the DB's "article" table in the "tags" column. If this is the
case, then maybe it would be best not to use a collection here, but
rather define tags as a normal property and then configure a different
editor (e.g. jquery.ui autocomplete) for it. I'm not sure if Create.js
supports this yet, but it should, since at some point, we will want to
use datepickers and the like, too

[dbu]

storage in phpcr is a multivalue field. in an orm a serialized array could be used. or a separate table with n-m relations. there is this tag plugin in create.js that afaik treats tags somehow as entities (CRUD of items in the dom structure but it does not end up being persisted separatly like a normal collection.) this is why i would love to see a working real-world example of the tags plugin with the minimum/best-practice html structure.
from how our mappings looked before, i start to think we could just configure a Type for string, as we have one for each entity class. but that type would then have one single property, the string value.

the plugin used to work in the cmf sandbox, but does no longer and either way i have no clue what we where doing... @bergie, is there a good example of that html structure somewhere? would love to do it the right way.