Realating TV's to Templates in a transport package.

Hi,

I’m packaging a few templates for revolution, so far so good with simple ones but to save much code searching .... I’m packaging a template with some chunks and two TV’s, I want to relate the TV’s to the template in the transport package, so I’ve created the rest of package OK, and I’ve created an XPDO object modTemplateVarTemplate to hold the mapping from templateid to tmplvarid for the template to the template variables. I used addOne to do this on the modTemplateVarTemplate object and packed it into the package thus :-



I get no errors on packaging, nor on install, the package is installed OK without the template/template variable mapping, a single row is inserted into this table with values of ’0’.

Ok, what attributes do I need to set here, obviously at packaging time no indexes are known, so I’m using my own(1,2,3 etc) and setting the XPDO_TRANSPORT_PRESERVE_KEYS => false attribute. if I don’t do this the addOne fails with a ’NULL field error’.

Is my thinking correct here or is there an easier way to do this?

You can’t insert cross-link records first; they depend on the primary keys of the objects they depend on, and unless you are forcing those keys in your install script, they will not be the same after installation. Insert the templates, then the TV’s, then the records that link them together. Also, identifying fields that serve to uniquely identify the object is important if you want to avoid inserting duplicates (i.e. tmplvarid + templateid would be unique for modTemplateVarTemplate, not just tmplvarid).

shamblett,

The only way to currently do this with objects that don’t have PKs is to use a resolver. The problem is that modTemplateVarTemplate is a multiple-PK object, in that it has 2 PKs - one for the modTemplate object, and another for the modTemplateVar object. Since those PK values aren’t known until after the TV and template are installed, there’s no way to relate them until after.

So, you’ll need to create a resolver. I’ve gone ahead and updated our test component (which demos stuff) to get this scenario to work. You can find the code here:

http://svn.modxcms.com/svn/modx-components/test/trunk/

Specifically, the build script. Note that you have to add the Template and TVs as separate vehicles:

http://svn.modxcms.com/svn/modx-components/test/trunk/_build/tests/templatetvs.test.php

And then attach a resolver. The resolver, here:

http://svn.modxcms.com/svn/modx-components/test/trunk/_build/resolvers/connect.tvs.resolver.php

Will properly connect the template to the TVs.

That’s the best way we can do it right now. Eventually we’ll hopefully get the RELATED_OBJECTS attribute to handle this better, but for now, that’s the best way to do it.

Ok thanks guys, I’ll have look at this ASAP, it’ll be nice to get a sort of template for this in my head at least.

As an aside is there any plan to create a GUI tool of some sort to help with packaging? I know this is difficult as its a difficult area, packaging RPM’s for instance is still largely done by crafting the spec file by hand. I’ve not seen or used any GUI tool that helps significantly for this task. The concern of course is that otherwise some contributors may be put off by this and that some users will simply resort to using 0.9.xx ways, where the code etc. is just placed under assets and included or manually install stuff by hand. If we have a packaging mechanism I believe we should try and push it as much as we can.

Quote from: shamblett at Nov 25, 2008, 07:09 PM

As an aside is there any plan to create a GUI tool of some sort to help with packaging? I know this is difficult as its a difficult area, packaging RPM’s for instance is still largely done by crafting the spec file by hand. I’ve not seen or used any GUI tool that helps significantly for this task. The concern of course is that otherwise some contributors may be put off by this and that some users will simply resort to using 0.9.xx ways, where the code etc. is just placed under assets and included or manually install stuff by hand. If we have a packaging mechanism I believe we should try and push it as much as we can.

We actually had a GUI for it at one point, but due to the unstable nature of creating the whole transport packaging system, it had to get reworked too much. Also, we found that the GUI really couldn’t handle the intricacies of packaging, and wasn’t really adept to do all that scripts can do.

So, we scrapped it for now, and maybe will rebuild it into future Revolution releases (such as 2.1). People can definitely still use the old way of doing things to install snippets, but they lose the ability of remote downloading and installing them.

We hope that we’ll be able to provide enough tutorials to make the process easier and more streamlined in the future.

Also, we found that the GUI really couldn’t handle the intricacies of packaging, and wasn’t really adept to do all that scripts can do.

Yes indeed, I think documentation with lots of boiler plate templates may be best here.

Ok splittingred, you’re code above worked a treat. The template and its TV’s are now correctly related. I found I had to do this before creating and adding the category vehicle or the install still works but the template and the TV’s do not appear under the newly created animetor category.

Also BTW my last svn update to just past alpha 6 is much faster than previously, especially installing/removing packages but the whole manager seems to be zippier, good stuff.

This is purely speculative, but if you have a lot of templates and TVs, I think you could put them in an array and actually create the PHP resolver source file that links them dynamically. You’d do this early in your build script, then give it as a source for a php resolver later on in the script.