I have custom model with different data types like string (file path) or double which should be edited using combobox with a few items.
It is not clear for me why delegates should be applied to views and not to models...
So, should I pass some kind of flag from my model and then use different delegates for those items according to those flags?
What is the best practice to make it?
EDIT: I'll try to clarify my question:
I have model with the map (key - value (structure that can contain different types like QVariant)) and it's necessary to set different delegates for each row of my, say, QTableView.
What is the best way to pass some "flag" for every item from my model and then handle this flag to set appropriate delegate for the given row?
EDIT2:
This model-view pair is for storage and editing software options with different types.
From the docs:
Unlike the Model-View-Controller pattern, the model/view design does not include a completely separate component for managing interaction with the user.
Delegates are supposed to tackle the "how" in "how should users interact with my data" (that's why I highlighted "interaction").
For your case, that very "double" field you provided, depending on it's interpretation, we could use a line edit (eg exact toleration), spinbox, or even some sort of color select (interpret the value as a color). Even more, one could use a line edit with some sort of color scale for the widget to make it more clear what consequence that value may have.
Correct way? They're tools, not one better than other but rather "one to tackle a specific problem". Can't tell what's the correct way from the info provided.
I suggest re-asking the question with much more info if you still have doubts.
Related
I will preface that this may not be the best use of a branch template, but it seems ok on paper, with a few drawbacks.
Sitecore 8, we have a Template called "Program." Program needs the ability to either be a two-column (9-3 grid) or a full (12-col grid). These basically represent a full version and a version with a right rail.
We want the content editors to be able to decide when they create the page whether they want a "program" or "program with right rail." To set this up, we created two branch templates. One that looks like this:
Layout: Base Layout
Renderings: Full (sublayout), Program Detail (rendering, dropped onto Full's placeholder)
And one that looks like this:
Layout: Base Layout
Renderings: Two-Column (sublayout), Program Detail (rendering, dropped onto Two-Column's placeholder)
Placeholder settings: Right Rail (allows right rail components to be added)
Then when the user right clicks on the "programs" item in the tree, they can pick one of the two options above and it creates the program item with the appropriate presentation details (again, either a full width or a two-col).
This all works, but the problem is if I ever have to change something on one of the branch templates, that change is not propagated to any items that were created based off of that branch like standard values works. There's no "branch delta" that I'm aware of.
Is there a better way to handle this? In my head, it essentially sounds like I need standard values for a branch template, but I don't think that exists.
Another thought I had was to create an "Program Master" template and then create two templates that inherit from it, Program and Program with Rail. That way they would share the same data but would have different standard values and allow me to set different presentation details for it. This feels a little dirty since I'd basically be creating a template to handle look and feel. I hope I'm explaining this correctly, but if not I'll update with more info if I'm being unclear.
Unfortunately if you want to take advantage of "layout deltas," out of the box you would need to have a separate template with its own standard values, as far as I'm aware.
You could probably do something fancy with the renderLayout pipeline if you wanted -- e.g. Sitecore Zen Garden introduces the concept of "Designs" which are used to define default layout, and allow you to separate layout from Standard Values. But you're going off the reservation at that point.
In Sitecore, I have a field which is re-used by several page templates. I use basepage inheritance, partly so I don't have to configure the source, help-text and so on each time it is used.
However there are times when the field has a slightly different meaning for one particular page template, and I would like to adjust the Title and help text accordingly to make it easier for the content editors.
Can anyone suggest a good way of doing this in Sitecore? Or is the solution just to make another copy of the field and edit that accordingly, especially as that's only a few seconds work.
Update: Thanks for the answers, I agree with all of them. The difference in the purpose of the fields was so subtle that I didn't think it warranted different fields, but I guess that's a kind of micro-optimisation that will just end up confusing everyone anyway, and certainly isn't worth developing a whole UI / datastore just for this purpose.
Good question, and one that most Sitecore people arrive at eventually. That fact is that the help text is part of the field item. So if you want different help text, you need a different field.
As you point out, the fields sometimes have a different meaning. This is an indicator that it should in fact be a different field.
My suspicion is that you're probably better defining the field more than once.
It may well be possible to modify how Sitecore generates the editing controls shown in Content Editor so that your field's title varies. But that implies you need to store some configuration somewhere to say "when should it change" and "what should it change to". And that's likely to take some time to set up. Plus I think that might be confusing to future developers on the project as it's unexpected behaviour for a field to change it's appearance in different places?
So I'd argue that multiple definitions of the field will be easier for other developers to understand, and probably less prone to mistakes.
If this is not a field that is different on every page, I would keep the inherited field, whether or not it is used by the current page, and create a new one to suit the changed purpose. If the field does have a different meaning on every page, then I would remove it from the base template and re-make it for each page template.
If you have this field on your base page template and it is used on most pages, you will want to ensure that you are still able to use it on the other pages that need it, even if there are one or two exceptions where it does not apply. However, if the purpose of this field changes on every page, then it is better architecture to create a separate field on each page.
It is best practice to use each field for a defined, uniform job; you should not be re-purposing fields between items, as it will lead to confusion for both developers and content editors.
Depending on how many templates you have it may be worth taking that field out of the base template and create two separate templates for these fields.
Essentially will probably have the same field name but with a different help text and title.
Then just inherit the one you want.
This way you keep it separate and this makes better sense being separated as mentioned above.
If you have loads of template already using it then maybe a quick script to swap these over before applying the new template to help change existing ones over (only if you have lots of templates using this base template already)
Hopefully I've made sense here.
As everyone has stated, you need different field for different page templates.
I would do the following, create a new template which contains your common field, and make page templates that use this field with same 'meaning' inherits the new template.
And for page templates that use this field with different meaning, add a separate field to each template.
I am trying to implement a ProxyModel that takes a source Model that represents a flat, table like structure.
Then you can select one column of this model as a grouping value.
The proxy model should then create as many top nodes as there are distinct values of this column and sort the underlying rows into them.
But when doing this, is subclassing QAbstractProxyModel a viable option?
Since mapToSource(const QModelIndex& proxyIndex) will not always return a valid source index for a valid proxy index.
Does someone have a better solution, perhaps just using a QAbstractItemModel without the built in proxy functionality?
Here are two example projects which address this issue, for anyone's future reference. (One of them is mine, I do not mean to spam, it just seems relevant.)
GroupedItemsProxyModel (doc)
QGroupingProxyModel (doc)
Edit (response to comment): Both projects implement what, I believe, the question is asking about. I think examining the source provides the best examples and would obviously be too long to paste it all here. I've provided links directly to the source and to relevant documentation.
UPDATE: Sorry, understood this a little wrong. I never derived from abstract proxy model so I am not sure about that. However I would start using a QSortFilterProxyModel. It may happen that it has some functionality you do not need but this does not hurt. On the other hand implementing your on proxy model could hurt since it requires additional work and know-how.
If you should experience problems switching from the non-grouped structure to the grouped structure within the proxy model consider switching the model of the view (one showing grouped data, one showing original un-grouped data).
I'm building an filebrowser based upon the QAbstractListModel and QListView.
As you know what is displayed can change, by making the window bigger, or by scrolling.
How can I determine the first and the last entry (or index) actually displayed. Do I have to program that myself?
Added later:
see for full description:
http://qt-project.org/forums/viewthread/26497/
Thanks in advance,
Stef Bon
Voorburg
the Netherlands
The reason provided in the comments is not adequate; the model is supposed to call beginInsertRows/endInsertRows at any time, even if the range where you are inserting items is not currently visible in the view. There are multiple reasons for that (proxy models, QPersistentModelIndex instances, selection handling, QAbstractItemView's internal housekeeping, caching of already rendered items etc).
The MVC API in Qt is designed so that the model is not supposed to know about what the view is currently showing. The contracts expressed in the QAbstractItemModel specify that the model "just" has to keep the rest of the world updated by calling the protected methods (which emit the rowsInserted etc signals, among other things). If you ever find yourself in a situation where you start thinking "hey, if only I knew how this model was displayed in the attached view", the correct thing is to make sure you are using the existing API effectively. As an example, a very common problem is that the programmer finds out that their model's data() method is called too often, for each item in a list, for example. The typical reason for this is that the corresponding QListView needs to know how much space to reserve for each item so that the scrollbar size can be determined. A correct way for this is to either return usable data for the SizeHintRole, or set the view's uniformRowSizes to true.
I would like to hear your opinion about this.
I have a django application, where the data obtained from the model are rough. To make them nicer I have to do some potentially complex, but not much, operation.
An example, suppose you have a model where the US state is encoded as two letter codes. In the html rendering, you want to present the user the full state name. I have a correspondence two-letters -> full name in another db table. Let's assume I don't want to perform joins.
I have two choices
have the view code extract the two-letter information from the model, then perform a query against the second table, obtain the full name, and put it in the context. The template renders the full state name.
create a custom filter which accepts two-letter codes, hits the db, and returns the full-length name. Have the view pass the two-letter information into the context, and put in the template the piping into the filter. The filter renders the two-letter code as a full string.
Now, these solutions seem equivalent, but they could not be, also from the design point of view. I'm kind of skeptical where to draw the line between the filter responsibility and the view responsibility. Solution 1 is doing the task of the filter in solution 2, it's just integrated within the view itself. Of course, if I have to call the filter multiple times within the same page, solution 1 is probably faster (unless the filter output is memoized).
What's your opinion in terms of design, proper coding and performance?
It seems to me your model should have a method to do the conversion. It seems like extra work to make a filter, and I don't think most Django developers would expect that sort of thing in a filter.
A filter is meant to be more generic - formatting and displaying data rather than lookups.
My oppinion is that the first solution is much cleaner from a design point of view. I'd like to see the template layer as just the final stage of presentation, where all the information is passed (in its final form) by the view.
It's better to have all the "computation logic" in the view. That, way:
It's much easier to read and comprehend (especially for a third party).
I you need to change something, you can focus on a particular view method and be sure that everything you need to change is in there (no need to switch back and forth from view to template).
As for performance, I think your point is right. If you want to do the same lookup multiple times, the 2nd solution is worse.
Edit:
Referring to ashchristopher's comment, I was actually trying to say that it definitely does not belong to the template. It's never really clear what business logic is and where the line between "data provision" and "business logic" lies. In this case it seems that maybe ashchristopher is right. Transformation of state codes to full state names is probably a more database related encoding matter, than a business logic one.