Just what I was going to do!
| Project: | Menuwriter |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
I don't believe it.
I've been putting off all day sitting down and writing this exact module!
With much the same approach!
Yesterday afternoon I figured I might as well do it properly rather than faff around with handmade mouseovers. I've always thought it would be a good thing to do. I planned it over last night, (and went shopping instead this morning)
So now I sit down and see this uploaded 15 minute before!
So far it actually does what it says on the box! unheard of for an unreleased commit ;-)
Only, here's the thing, I was hoping to be able to re-use the signwriter profiles (and UI) to define the various required states - and then just stitch them together (into sprites like this) in the menu-writer phase.
I'm not sure that it's great to branch so completely from the signwriter codebase if it could be possible to have signwriter as a dependency - then provide a wrapper to its UI.
As it is, it looks like a lot of duplicated code at the moment.
Other ideas include
- Adding css-generation assistance - we can produce a dynamic (yet cached) css based on the measurements set in the UI.
- Making one huge menu-label sprite that gets loaded once and offset by multiples
I hadn't thought of overriding the menu tree builder altogether - but knew I'd have to force a class or ID in there sometime. Looks like your method is pretty sound.
What do you think about factoring it back to re-use the big daddy options? It will halve the size of your code!
.dan.
#1
Hi Dan,
I have been working on this pretty solidly for about 2 weeks and I am sick of it so I am happy that you have some suggestions. I agree that it would be better to have Signwriter as a dependency. I just couldn't work out how to do that with out making the UI or the code too confusing. I thought if I posted it maybe someone would have some good ideas. I didn't think it would happen so quickly.
I have added some columns to the database table and have some extra variables to get all the features required but if you have an alternative then I am all ears.
Regards
Geoff
#2
I'm hacking at it now. :-B
Basically I've thrown out all the custom profile stuff (like - all of it and its database) and am keeping your UI - menu - allocation bit and overall approach, but selecting from the available signwriter profiles.
Just rebuilding the framework at the moment - I'll see what the diff between your profiles and the signwriter ones is soon. (IMO the signwriter DB schema needs an update)
I may be able to automate it a bit - like be ensuring that some values (height and width) are cloned to create sets, or have a base profile and delta changes upon that. Maybe not.
Using FAPI, I can even hijack, wrap, and re-use the signwriter forms if needed, but that probably won't be neccessary.
Still just fooling around and looking for stuff to re-use. (currently re-fixing signwriters png transparency issues).
I'm interested in this because I want to bring signwriter up to the point where it's abstract and useful as an API for my imagecache_actions ...
Maybe we'll all land on the same page eventually.
My current version will be built alongside yours for now, we can compare notes when I've got my rework into a proof-of-concept again.
.dan.
#3
Sounds good. I'm sure Agileware will be interested in abstracting Signwriter. While you are looking at new things check out how I used Signwriter to create vertical dynamic heading for views tables at http://www.col.net.au/contractors. I think that is something we could add as well somewhere down the track.
Geoff
#4
This sounds really interesting! I will most likely use this module as-is for now. But I like the idea of depending on Signwriter too.
#5
Hi TwoD,
Glad you like it. I think it will become popular with designers.
Please send me a link to any site that uses it and I will use it as an example site
Regards
Geoff
#6