I need to know if I am going about something the right way.
For a given page, I am instantiating an object for the page itself. Let's call that object myPage. Within the page I have containers (usually div tags). When I go to an admin component to work with a specific div, I instantiate an object for that as well. Let's call that myDiv.
Now, one of the things I want to work with for a given div is the styling of that div. So normally I would think that I'd just put in some style-related methods, such as myDiv.getPadding() or myDiv.getBackgroundColor(), etc.
But it occurs to me that I may eventually have other objects for which I may also need to do style-related stuff.
Given this, should I then create a separate style.cfc? Would that then be extended by the div object? Or would the style object extend the div object? My understanding is that the more specific object extends the less specific one, but I am not sure which is more specific in this case: is it the div object, which references a specific div, or the style object, which provides a specific set of data?
Thanks in advance!
First, unless you need to write styles on-the-fly, I would create one or more stylesheets and link them dynamically, instead of creating them dynamically.
Assuming, however, that you do need to create them on-the-fly...
I would not have either the control (div) extend the style or vice-versa. A style is not a more specific definition of a div, nor is the reverse true. What I would do is create a style object that only contains the display meta-data for a given element or element set. This can be contained within your control/div object (not an extension), or can be part of the page object. The style is definitely related to the control, but I would not combine them, as that makes it harder to separate content and presentation.
By no means am I saying this is the best approach, but if you really wanted to use CFCs to style your pages, you could have a DivTag.cfc extend an HtmlTag.cfc, which would act as your base class for all HTML tags. You could then compose a StyleAttribute.cfc into your HtmlTag.cfc to work with any style properties, such as background colors and padding. So then you would end up calling functions like myDiv.getStyle().getPadding().
In general, you should really try to favor composition ("has a") over inheritance ("is a") and not get too crazy with your component hierarchies. In this case, I'd recommend using CSS files to style your pages.
Related
In re-frame, components will be automatically updated when a subscription they deref has an update. This is generally used for all kinds of dom elements under a single element (in general a div) somewhere under html>body.
I would like to do the same for style that lives under html>head, i.e. the style should be updated in response to subscription updates.
The spade library allows one to define
"global" style, which is easy to setup once and for all
inline style, which is generated in the react/reagent component's render function and as such can be updated based on subscriptions *)
Now I would like to define style that is not inline, yet is reactive to subscriptions. How can this be done?
My best idea currently is to try to call (reagent.dom/render [my-style] head-el) a second time (in addition to the main rendering done to that div under html>body). Not sure if that is possible or idiomatic.
*) Although only (defattrs) is strictly speaking "inline style" (i.e. something like <elem style=...>), the other option (defclass) (being rendered as <elem class=...> with a corresponding style definition under html>head) is similar in that the style is always updated together with the element, i.e. I cannot seem to update the style of the class separately from rendering the element, e.g. one subscription leads to element changes, whereas another subscription leads to style changes (only).
I have an elm app designed with the Elm Architecture in mind. I've used it for all the samples in the tutorial and they work fine. I have the following components
ContainerListView
ContainerView
AddressView
RegistrationView
...
The ContainerView component is a very formatted div structure that is used to contain other views (but for now, only 1 at a time)
ContainerListView can contain multiple containerViews. It handles their presentation and positioning. You can think of it as an MDI surface
A menu from the main ui is used to add new container views to the container view list.
I'm presented with with three main questions. Two of them are
How do I create the components such that Container view can contain any other element is I pass in for example the init, update, and view functions and expect all things to be wired correctly? At the moment, the samle views I have are kinda hard-coded. They know exactly who the children is.
Some of the components require access to things like url, access token, etc. Does this always have to be passed in from main to the individual components or it can come from another source which will essentially be readonly and maybe updatable only from main?
I'm not sure if these two should be individual questions on their own. Any information on how to architect larger apps beyound hello world will also be appreciated.
I'm working on something similar! Nested controls. I too have a container object which knows about all the types that it can handle, and has basically case statements to handle each type. So I can't drop in a new control type and expect it to handle it, that requires altering the container.
As far as I know elm doesn't have type classes, which would be how I might try to handle that kind of abstraction in haskell or purescript. There's more about that here:
https://github.com/elm-lang/elm-compiler/issues/38
and here:
https://github.com/elm-lang/elm-compiler/issues/1039
The upshot appears to be that they don't know how they want to solve that problem yet, so they haven't.
Those are three concepts on Yii that I really don't get what should we use, on what scenarios?
Can anyone be kind enough to clarify those Yii elements, and on what situation should we use them?
In documentation of CForm one can read the following:
...we can divide a form
in two parts: those that specify each individual form inputs, and
those that decorate the form inputs. A CForm object represents the former part...
...and CActiveForm represents the latter.
In other words, CForm specifies elements of the form but CActiveForm (being a widget) renders it.
Looking at the source code we state that CForm can also render() itself and its rendering relies on and is wrapped by CActiveForm widget by introducing its configuration property activeForm, though rendering input elements and buttons is implemented by its own methods renderElements() and renderButtons() relatively. By default their implementations rely on classes using CHtml's static methods what is exactly the same (or almost exactly the same) what CActiveForm's rendering methods do. Of course, default behavior can be overriden by extending the class.
That's why it's the question of a taste which technique to use: CActiveForm widget alone combining form fields' and buttons' declaration with their representation in a view file by calling convenient (required) methods of CActiveForm instance or CForm class declaring form's input specifications in a separate configuration file and customizing its rendering by pointing at appropriate active form widget and/or by overriding default rendering methods. The latter technique allows to reuse a form in several actions easily and is no more than using form builder.
Check here for live examples of ActiveForm, CForm, et cetera. You can also see the live Model, View & Controller files.
Observe the following classes and their containment:
Section has an ItemList which has many Items
But lets say an Item is rendered a different color based on some complicated algorithm that is based off the Section.name it is contained in.
What's the proper/best way to go about abstracting this functionality? Is there a common design pattern that occurs in situations like these? Or is the inherent design flawed?
You should separate your data structures/models from your logic and processing of them. That said, I would make your Item have a Section reference on it referencing it's Section, when you add an Item to the ItemList, ensure the add method looks at the ItemLists Section (parent) and sets the reference on the Item. Same goes for the setter on the ItemList in the Section, it would have to iterate each Item and set the Section.
Alternatively, you could make the Section set on the getter of the ItemList as lazy semantics, that would be entirely up to you depending on the use of your Section the performance statistics would be different between these two approaches.
Further, I would write some form of renderer that took an Item and knew how to render it which would look at the Section on the Item and the Name on that Section.
You may want to render an entire section, but I would write that renderer separate and it would use the ItemRenderer to render each Item.
As an aside, you may want to use a form of IObservableCollection and have the Item implement INotifyPropertyChanged as well so that you could then maintain synchrony both between the rendered version and the item, and synchronize the Item with the Section it exists in by an event registration that updates the Section property appropriately.
What does the rendering? If it's something in Section, or outside of all of these, but accessing the Items from the Section, then there's nothing more needed.
If it's in Item, then you just need to make sure Item knows what Section it belongs to, or can obtain it (e.g. by having an ID it can look up on - useful with languages that make dealing with circular references tricky, but not needless hassle otherwise).
Since the first case causes no difficulty, it's clearly to be preferred over the second, so the closest to a design-pattern is that if you find yourself doing this sort of work in the contained item, to try and move it up to the container, or outside of them all. Beyond that, there isn't much of a problem to need solving.
I would build an ItemRenderer class that knows the algorithm, and pass in the references to each Item you would like to render and the Section it was contained in.
It may also make sense to let each Item know the section it belongs to, but I would still let the ItemRenderer handle the rendering.
I was experimenting with Dojo and Dijit in the past days and I find it quite interesting. I was however trying to find a reference or an API doc that helps me understand all the properties I can assign to widgets and containers.
For example a Tab with a Save Icon will be like this:
<div data-dojo-type="dijit.layout.ContentPane" title="Group Two" data-dojo-props="iconClass: 'dijitEditorIcon dijitEditorIconSave'">
Now, where can I find what to put in the "data-dojo-props" property? Where can I find for example all the list of icons?
My main question would be for example on how to create a vertical menubar, but beyond odd examples scattered here and there, the api reference is not much helpful...
Any help? Am I missing something here?
For this kind of situation, the trick is learning how to convert between the programmatic Javascript style and the declarative HTML style (and sometimes also between the old declarative style, without data).
For the new declarative style, basically the only "real" argument now is data-dojo-props and it consists of an object that will be passed to the widget constructor.
//programatic style
new dijit.myWidget({foo:'a', bar:'b'});
//declarative style
<div data-dojo-type="dijit.myWidget" data-dojo-props="foo:'a', bar:'b'"></div>
You can find what properties an widget accepts by checking the corresponding widget documentation and looking for either declarative or programmatic examples (now that we know how to convert between them). If that is not enough, you can also check the source code - it is usually very well commented and is where api.dojotoolkit.org gets its data from anyway.