I have an asset that needs to make use of the features of File and Page assets.
The idea is that the content of a Page will be generated from the output of a Word2k3 or OOo doc run through an xml parse to produce HTML. The document is also attached as a seperate sub asset of the new page.
The way I see this happening is as follows;
The Create stuff happens as normal (just the name)
[*]A file upload field is available on the Details screen
[*]The uploaded document is parsed and the content added as Content DIV's
[*]The file is attached as a sub asset.
I'm needing to make use of features in the Page Asset and File Asset to make this work though.
Can anyone provide any pointers on how adding an asset actually works? Currently it's been a blackbox type affair but this module is forcing me to have to dig a little further into the guts of things. I'm going to need to take a file that has been uploaded and add it below the previously created asset.
I'm assuming that in the class that extends [font="Courier"]Page_Edit_Fns[/font] I'm going to have to include and extend [font="Courier"]SQ_INCLUDE_PATH.'/asset_edit/asset_edit_fns.inc'[/font] to add the file as an asset...
I'll assume that you mean adding an asset type to the system, not adding an asset from the menu
If you have a look at page_standard in the core package (SYSTEM_ROOT/core/asset/page_templates/page_standard) you will see the following files:
asset.xml (describes the asset type and any dependencies that it may have)
page_standard.inc
page_stanard_edit_fns.inc (functioning used to paint and process the backend)
page_standard_management.inc (defines any attributes that the asset may require)
edit_interface_screen_contents.xml (defines the contents screen LnF)
edit_interface_screens.xml (defines any addition screens that this asset displays)
You best bet is to copy the page_standard into a new package into the SYSTEM_ROOT/packages directory and start from there.
I think the best option for your solution is when the Word/OOo asset is created, you choose a file asset using an asset finder that contains the document that you want to generate the html from. This way you wont have to duplicate code from the file asset into your new asset type and can easily designate a new file later. Once the new asset has been chosen, create a new link to it. Once you have done this, it should be easy to get the document, and generate the html from it.
If you look at the Design code (in [font=“Courier”]core/assets/designs/design[/font]), you’ll see an example of an asset that accepts uploaded files and processes them in the edit_fns.inc. However, in that case the uploaded file is not available externally in its original format and is not created as a sub-asset (the original file contents exist as an attribute of the Design asset).
However, it does also allow you to upload associated files, which ARE created as sub-assets and are available externally. So, a combination of the parse file processing code and the associated file upload and asset creation is probably what you’re after.
P.S. the design code is currently being overhauled, so no comments about the lack of coding standards compliance, mmkay?
I’ve ripped a <section /> from [font=“Courier”]core/assets/designs/design/edit_interface_screen_details.xml[/font] and made slight modifications to it (one upload field etc) I’ve also grabbed the paint and process functions and put them in [font=“Courier”]page_office_importer_edit_fns.inc[/font]
However, when I Lock the details screen for editing the upload field doesn’t appear. I’m thinking that either it’s something to do with the write/read_access for the section (below) or something with the file_upload() function. There’s not enough in that function to go wrong though…
the function names match those in [font=“Courier”]page_office_importer_edit_fns.inc[/font] but they don’t seem to be being called.
...
Upload Document
File must be either OpenOffice.org, StarOffice or MS Word 2003 (new XML) formats.
...
Its to do with the write_access="write:parsing" and the locks that the Details page usually takes. I'm away from my usual PC at the moment, so I can't dig up example code, but the Design asset should define the locks required to achieve a "parsing" lock – you may want to rename that as well.
Once you actually achieve the locks that are appropriate, you'll get the appropriate output from paintNewFile (and note that the function itself tests for write access before enabling the upload form). It would be worthwhile taking a look at the File asset itself as a comparison, to see what is display with/without a lock.
Cool. I understood most of that but have no idea where to look for the details. If you could (tomorrow) would you be able to post some pointers on this? Maybe a brief on how the locking works, what a lock is, how to define/test for/acheive/release a lock etc?
Yup. I'm not sure how much free time I'll have tomorrow (I have a rather large client going live in a week! Eeep!), but I should be able to whip up something.
I'm up to my eyeballs at the moment, so I don't have a lot of time to find the appropriate code. In the meantime, you can change write:parsing to write:all and that'll work (the 'all' lock is global).
