Futurescale, Inc.
PureMVC Home
The PureMVC Framework
Code at the Speed of Thought
Over 10 years of community discussion and knowledge are maintained here as a read-only archive.
New discussions should be taken up in issues on the appropriate projects at
https://github.com/PureMVC
PureMVC Architects Lounge
Announcements and General Discussion
General Discussion
How to solve this thingy in an elegant way?
Pages: [
1
]
« previous
next »
Author
Topic: How to solve this thingy in an elegant way? (Read 14543 times)
archont
Newbie
Posts: 3
How to solve this thingy in an elegant way?
«
on:
August 23, 2009, 03:28:20 »
I'm building a skinnable application. Before the application loads the skins, styles and fonts need to be loaded. I decided that three proxies, one for the decals, one for the CSS and one for the fonts would be an ok idea. I integrated that with the startup utility as, well, the fonts proxy needs to know what fonts are used in the CSS, and using it appeared to be a good idea.
Now here comes the problem however. The very idea of skinning is that I can throw a new LabelComponent("Label #AboutUs") and it works. However that means that a view component needs to keep a reference to the proxy in order to actually get and apply the CSS formatting. Worse, whenever I need any graphic at all, be it a simple button or a logo, I need to get it from my DecalProxy. This led to a situation where most of the viewcomponents are using the proxy to get the concrete data they need.
Now I realize this isn't a very elegant solution. On a scale from Pretty to Unelegant it's probably somewhere around "Beat with an ugly stick".
What's the best course to remedy this? Should I create an interface for the proxies and pass them as constructor arguments or maybe a static var? Should I remove the skinning functionality from the components and move it into the mediator? Or should I create a viewcomponent factory?
Logged
dihardja
Jr. Member
Posts: 17
Re: How to solve this thingy in an elegant way?
«
Reply #1 on:
August 24, 2009, 02:02:35 »
Hi,
maybe you would handle that through the mediators. for example
1) after all of the 3 proxies are loaded , send a notification
2) each mediator of the specific component which listens to the notification then setup their view components with the data from the proxies
Logged
archont
Newbie
Posts: 3
Re: How to solve this thingy in an elegant way?
«
Reply #2 on:
August 24, 2009, 09:09:31 »
I could, however it would be a massive overhead. The skinnable view component is a textfield. An auto-configurating textfield, but essentially it serves no purpose beyond being a textfield. Making a Mediator for every little decoration, textfield and such would be a massive waste, I think.
However a Mediator Factory (or should it be a Proxy? ) that produces these components might just be a good idea.
Logged
puremvc
Global Moderator
Hero Member
Posts: 2871
Re: How to solve this thingy in an elegant way?
«
Reply #3 on:
August 24, 2009, 10:24:42 »
This sounds like a job for a Command that does the factory logic, retrieving the proxy, creating the component with info from the proxy. Then send the component off in a notification heard by a Mediator which hands it off to its view component to insert into the view hierarchy. If a mediator is needed, the command can wrap the component in a mediator and register it before sending off the note that causes the component to show up in the hierarchy.
-=Cliff>
Logged
hesten
Sr. Member
Posts: 52
Re: How to solve this thingy in an elegant way?
«
Reply #4 on:
August 25, 2009, 12:14:13 »
Why would you use a Command to do factory work? Isn't that a bit like forcing a PMVC "paradigm", on the problem?
Couldn't you have a factory or builder that could construct your labels or whatever, and have a command create and/or populate that factory with css, fonts a.s.o (and make the methods for retrieving from the factory static, since every view component potentially needs a label)?
Logged
puremvc
Global Moderator
Hero Member
Posts: 2871
Re: How to solve this thingy in an elegant way?
«
Reply #5 on:
August 26, 2009, 12:46:45 »
Sure you could do that. Are you saying the view components would call these static methods to add the labels to themselves?
-=Cliff>
Logged
hesten
Sr. Member
Posts: 52
Re: How to solve this thingy in an elegant way?
«
Reply #6 on:
August 27, 2009, 02:34:18 »
In an application that needs special fonts for every single label/textfield, yes I would make the method for getting a textfield with a given textformat static, and let view components get the information themselves.
I'm not sure it's considered good practice (since it makes the view components dependent on the factory), but it is very handy.
Logged
Jason MacDonald
Sr. Member
Posts: 243
Re: How to solve this thingy in an elegant way?
«
Reply #7 on:
August 27, 2009, 06:21:25 »
Have you looked at how Flex and the Flash UI Components handle this? I borrowed ideas from both Flex and Flash for my component framework. My base component handles most of the styling (getStyle() and setStyle() etc) using a singleton StyleManager. The style manager is what I use in my proxy's to store the style info. I do a similar thing for Fonts using a FontManager singleton. This allows me to use my components in any framework, no direct ties to PMVC at all.
I use a XML based style sheet. My Proxy parses the XML and sets the groups/styles on the StyleManager that is later called by the base of each component to get and set style information for that component. I use a className variable to handle inheritance. As each level of the component heirchy is loaded, I have the base component call a query on the StyleManager for any styles matching "TabBar" for eaxmple. As it walks up the herichy (parent may be just "ButtonBar") it grabs styling for each level of the component. It checks along the way for which styles are allowed to override the children and which are not. This is the same concept as Flex style inheritance.
There's more to it that just that, but that is kind of the jist of it.
«
Last Edit: August 27, 2009, 06:23:16 by Jason MacDonald
»
Logged
Pages: [
1
]
« previous
next »
Stack Overflow
GitHub
Linked In
Google Plus
Twitter
Powered by SMF 2.0.15
|
SMF © 2006-2007, Simple Machines LLC
|
Content © 2006-2018, Futurescale, Inc.
Loading...