I have to edit a document which has been tagged semantically.
Assume I have an HTML document where some or all paragraphs (or span) have been tagged with a specific class name, something like: <p class="bio"><span class="name">John</span><span class="surname">Doe</span>is a <span class="job">carpenter</span> living in <span class="place">York</span>.</p><p class="story">He was working at his bench when...</p>
I want to use a QTextEdit widget to edit such text (if possible).
Additional requirements are:
Each class should have specific graphic rendering (this should be easy using CSS).
Editing specific <span> should preserve class (i.e.: if I edit "John" -> "Jonathan" it should still have class="name").
I should be able to apply class to specific pieces of text (i.e.: select some text, open a context menu and select one of the possible classes).
Remove tagging from selection.
Serialize edited text (i.e.: walk the edited text, recognize class changes and be able to produce whatever markup I want).
Note classes can be contained one inside another (but not overlap partially); this means some piece of code has two (or more) classes.
Can this be achieved with standard means?
As far as I have seen QTextDocument and associated classes (e.g.: QTextFrame, QTextFormat, etc.) are geared toward visual representation (font style, color etc.) while I need some "logic" tagging that may or may not reflect in visual changes. I mean: text can be all in the same font/color/background, but moving cursor over it I should be able to list all classes active in that specific place (if any).
I am coding in PyQt5, if this is relevant.
The only (rather ugly!) way I seem to see to achieve this is to use QTextCharFormat's tooltip property to store class(es) of each QTextFragment. Is there a better option?
For anyone having the same problem:
QTextCharFormat has a property (named "Property") which can be used to hold arbitrary data.
You need to:
define your set of codes (higher than QtGui.QTextFormat.UserProperty to avoid clash with existing properties).
set with: format.setProperty(mycode, myvalue)
read back with: value = format.property(mycode)
Other Widgets have similar (but NOT identical!) mechanisms (e.g.: QStandardItem has a similar property called data)
IMPORTANT NOTE: if you are using PyQt there are severe restrictions in what you can store and safely retrieve (storing a QTextDocument in a QStandardItem.setData(doc, mycode) will not work reliably because only the reference will be stored and if the underlying python object is garbage collected you'll have a nice crash (SIGSEGV).
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).
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.
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.