I recently came to this idea and wrote about it to Nic Hubbard who thought it is awesome…
Idea is to collect beneth this topic tutorial requests (what You wanna see on Squiz Community site).
Cheers, Paul
Squiz Community tutorial requests
[quote]
I recently came to this idea and wrote about it to Nic Hubbard who thought it is awesome…
Idea is to collect beneth this topic tutorial requests (what You wanna see on Squiz Community site).
Cheers, Paul
[/quote]
we've been slowly adapting the EES to work for customisations that exist in matrix - replicating what you could to by adding metadata to an asset and presenting an interface via a 'simple edit layout'. that sort of tutorial /documentation is a bit absent at the moment (not even sure if we're on the right track as we've not put it live to the users yet).
K
Hey kjb, just to clarify is this using the Easy Edit Suite or creating your own backend? What context are you looking at…
[quote]
Hey kjb, just to clarify is this using the Easy Edit Suite or creating your own backend? What context are you looking at…
[/quote]
…just adapting the EES. Ok an example. say you have a calendar asset and you attach a metadata scheme that has additional event data. Using the ‘old’ matrix way you could add a simple edit layout as the details screen so that then ‘_edit’ is called that simple edit layout is used (listing core calendar fields but also the metadata). The EES way (i think) would be to hide the tabs you don’t want then hide the tabs the extends EES to customise the editing interface to incorporate your metadata elements. Something like:
EasyEditScreens.assetTypes.calendar_event_single = { config: { "New screen": { objectName: "newScreenDefault", className: "newScreen", lockType: ["attributes", "links"], isDefault: false } } }
and
EasyEditScreens.screen.newScreenDefault = { containerId: null, init: function () { EasyEditEventManager.bind('EasyEditAfterLoad',self.functionFoo); callback.call(this); }functionFoo: function() { // Functionality here, called after the EES has loaded ('EasyEditAfterLoad') } }</pre><br />
Then you are off. The above is based on trial and error thus far - hence a tutorial from a wider/wiser group would be good... (you did ask :-P
K
Cool, I see. At the moment we don't have the EES installed on the system but when we do I'd also be very interested in learning more about this too.
Bump. Anyone want a specific tutorial written? I'm in the mood to write something awesome. Any takers?
[quote]
Bump. Anyone want a specific tutorial written? I'm in the mood to write something awesome. Any takers?
[/quote]
You're a wise guy, so I'll try…
First a story
We link the same assets in many places (as 1st children of folder assets). Folder assets are separated from rest of our Sites and resides below Site that has no URL.
My work-collegue long time ago wrote a javascript which keeps connection between Metadata of the asset and locations where asset is linked. Metadata is used when editing asset for a quick check where asset is linked. This works quite well, but sometimes asset is not created after building an asset, also connection between Metadata and linking sometimes brakes. It is hard to add new "linking" places in this solution (Asset Builders & Metadata Schemas & some javascript need to be edited manually), but assets can be linked in all places at once with a fake feel of linking asset to many trees at once (distance from a root is manually kept in Metadata).
Lastly I wrote some jQuery code to add tree view for Asset Linking Page Link Manager Page (corrected). I just added via jQuery to every Folder asset in it's Metadata a distance between all Root Assets that I use later. I thought I would take us forward, but I'm not happy with my solution. I need to create fake trees (creating them takes a long time) for my Asset Builders and I don't know how to exclude folder assets. On bigger trees - Asset Linking Page Link Manager Page loads slowly. Also I can link asset to one tree at once.
Then my question
So maybe You know how to solve our problem?
The problem is "just" linking an asset to many places at once with a tree view & fast linking editing & fast adding new linking places.
I'm looking more for a good idea which works on big sites, but some tutorial would be even better
Let me think about the best way for you to get this working. Do you have an example of this on your site?
[quote]
The problem is "just" linking an asset to many places at once with a tree view & fast linking editing & fast adding new linking places.
I'm looking more for a good idea which works on big sites, but some tutorial would be even better
[/quote]
Have you looked at using a link manager page asset?
Lastly I wrote Asset Linking Page, but it should be Link Manager Page. I corrected it in my earlier post.
Nick: Yes, I tried. For Link Manager Page I need to create fake trees (creating them takes a long time), also Link Manager Page loads slowly on bigger trees
Duncan: I created some images - maybe it will help.
So here are “Folder assets are separated from rest of our Sites and resides below Site that has no URL.”
(This is only a very small part of it. Tree is very big.)
[attachment=532:20120329 16.58.55_pw.jpg]
Here is a look at my work-collegue solution
(Linking assets with metadata and javascript. Fake tree view need to be edited manually. Shows very fast to user.)
[attachment=534:20120329 16.52.05_pw.jpg]
Here is my solution based on Link Manager Page
(Linking only to one root at once. More automatic. Showing a tree takes a some time.)
[attachment=533:20120329 16.56.08_pw.jpg]
20120329 16.58.55_pw.jpg (49 KB)
20120329 16.56.08_pw.jpg (27.6 KB)
20120329 16.52.05_pw.jpg (44.2 KB)
A tutorial on using nested content, asset listings, asset builders and other assets utilising the GET, POST, SESSION and other variables would be nice. I've been trying to figure out how to use them and pass information from page to page, but some guidance on the topic would be nice along with a real world example.
Ok, that sounds like a useful one and something we've done before. Ok, cool. Let me see if I could make something cool for you.
Uam, thanks for the screenshots…
[quote]
Bump. Anyone want a specific tutorial written? I'm in the mood to write something awesome. Any takers?
[/quote]
Hi Duncan - what a great offer!
I would really like a tutorial about cache settings, as I really feel it could improve performance on my sites, but I have no idea about where to start.
EG what settings for a standard page.
What settings for a page that brings in external content that changes on a daily basis (I have a weather report in an external txt file, took me ages to stop it caching for public users!).
What settings for pdf files that aren't going to change.
What about pages that nest in asset listings set to display random content?
Im sure there are other types of content/situations that require specific cache settings.
If anyone is up for a 'Become a cache master' tutorial, I'd find it incredibly useful!
Thanks!
Charlie.
Hey Charlie,
That's a very interesting idea. It's something which we've been looking at recently too especially with /_performance in newer builds. I could give it a go for sure…
I second Charlie's request. Would also like some more info about interpreting the /_performance results. Thx
[quote]
I second Charlie's request. Would also like some more info about interpreting the /_performance results. Thx
[/quote]
Here is a Squiz Labs post about it: http://www.squizlabs.com/squiz-matrix/squiz-matrix-performance-mode
[quote]
…just adapting the EES. Ok an example. say you have a calendar asset and you attach a metadata scheme that has additional event data. Using the ‘old’ matrix way you could add a simple edit layout as the details screen so that then ‘_edit’ is called that simple edit layout is used (listing core calendar fields but also the metadata). The EES way (i think) would be to hide the tabs you don’t want then hide the tabs the extends EES to customise the editing interface to incorporate your metadata elements.
[/quote]
Hi KJB
I would avoid complex custom work that adds metadata fields to separate screens to to existing screens other than the metadata screen, otherwise this could be a bit of a maintenance mess and hard to upgrade. Also re-using core code could easily break later on down the track if we decide to change this.
Considering EES has a metadata screen out of the box, I would just educate users to use the two screens (details and metadata) to complete their publishing tasks. If the metadata screen has too much data on it then you could look at a plugin that fires on screen load (and screen is metadata) to quietly hide the things that are not required.
Cheers
Scotty