Runtime Asset Creation

(Nic Hubbard) #1

I was just reading the page on Runtime Asset Creation on the create asset tutorial. It didn't give too much detail about how to use the function, so here are my questions.


Which file would this function go into? <asset>.inc?

Where should I call the function from?



Here is the example I am going to work off of:


    function createBodyCopy()
    {
    	// new Bodycopy object
    	$asset =& new Bodycopy();
    	// we need to link the new asset under this asset, with type 2 link,
    	// it will be dependant and exclusive
    	$link = Array(
    				'asset'		=> &$this,
    				'value'		=> 'page_contents',
    				'link_type'	=> SQ_LINK_TYPE_2,
    				'is_dependant' => 1,
    				'is_exclusive' => 1,
    			);
    
    	// set the name of the new asset
    	$asset->setAttrValue('name', 'Page Contents');
    	
    	// try to create the new asset
    	if (!$asset->create($link)) {
    		echo translate('failed_to_create_asset');
    		return FALSE;
    	}
    	
    	return TRUE;
    
    }
(Greg Sherwood) #2

The function normally goes into <asset>.inc if it is used on the frontend or in <asset>_edit_fns.inc if it is only used in the backend. It doesn't really matter where you put it. If it's in the <asset>_edit_fns.inc file, you just need to get the edit functions object before you can call it. See asset.inc for how to do it (getAssetEditFns() or something, can't access the code right now).

(Uberdrag) #3

Hm… I've just managed to create a new custom asset and install it via running step03 and locale scripts after defining the basic interface in a proper files (management + xmls) and I realized that the updates to the assets are not runtime… How come? It's merely possible to develop that way.


This link provided by Nic is lack of information, I would like to know if I can update my custom asset, it's interfaces and functionality without always recompiling the package?



Thanks :slight_smile:

(Ashish Karelia) #4

Hi,

[quote]

Hm… I've just managed to create a new custom asset and install it via running step03 and locale scripts after defining the basic interface in a proper files (management + xmls) and I realized that the updates to the assets are not runtime… How come? It's merely possible to develop that way.

[/quote]

I am not quiet sure what you mean by "I realized that the updates to the assets are not runtime". Can you elaborate for me to comment on it please.


[quote]

This link provided by Nic is lack of information, I would like to know if I can update my custom asset, it's interfaces and functionality without always recompiling the package?

[/quote]



If you make any changes to the XML for the Editing interface screens, you will always have to execute the compile_locale.php for Matrix to introduce those changes. Like wise change to the <asset>_management.inc file will always need a step_03.php to be run.

If you are changing the functionality for the custom asset by changing/adding/removing code in <asset>.inc file no installation steps are needed. This should be reflected right away. Like wise if your XML files are calling functions from <asset>_edit_fns.inc file to paint and process the backend interface of the asset, you won't need to run the installation steps.



Hope this helps, feel free to ask any question if anything confuses you,



Ash

(Uberdrag) #5

Hi, thanks for reply.


I meant in this sentense: "I realized that the updates to the assets are not runtime"



That, when you update something in your custom asset, like interface (XML files) or management files, you have to recompile It by running either step03 or locale file, and this must be done everytime I do changes in this files.



As I can see, you're a Developer, tell me, this is the way how you guys add new assets as well?

How about controlling the output before it renders on the page?

I would like to inject custom interface elements, as the XML parser and the abilities provided out of the box are not sufficient for me.



For examle, I would like to do a cURL request in my Asset and parse the response in a table-list, but I can't, because there's no methods controlling the output before It actually renders, besides "paintBackend" which, if you redeclare It, will not process the actual XML files and management files and will not output the interface you've specified in these files.



So,

  1. Can I change output before it renders?
  2. Can I update the XML/management files without recompiling all the time?
  3. How do you guys develop assets? Squiz looks very useful for end-user, but (I'm sorry) horrible for developers. The extensibility is seriously harmed.

    Which is not what usually open source systems provide. Usually there's HOWTOs for developers, community and ability to easy write new modules. :slight_smile:



    Thanks again and I beg pardon for criticism, we're just having hard times extending the system…
(Benjamin Pearson) #6

[quote]

  1. Can I change output before it renders?

    [/quote]



    If you want a dynamic backend, usually the XML files contain 2 function calls; one to paint and one to process. For example, in the XML you would have:


And then, in the *_edit_fns.inc file of the asset, you would place your function calls "paintFunction" and "processFunction". Now you only have to run step3/compile_locale once to pick up the new code and to change what it paints you would change the "paintFunction" call.

A similar approach can be used for the management file as well, if you need dynamic attributes to the custom asset; create an attribute with a type of "serialise". Then it would be a matter of using attr('customAttribute') to get all of your attributes (accessing them as an array) then using setAttrValue() to set them back (and saveAttributes() to commit to database).

[quote]
2) Can I update the XML/management files without recompiling all the time?
[/quote]

No, but using the above methods allows you to have dynamic backends and attributes. Aside from checking the contents of the XML/Management files, it also registers the screens and attributes within Matrix mainly so there is no need to parse the XML/Management files at runtime.

Hope that helps
(Uberdrag) #7

Thanks a lot, Benjamin.


We'll give it a try now.