I feel like this should be in the documentation but it's just not (actually a lot of things are not) so I'm just very confused.
All I need is a searchable selectbox that works exactly like the html version. I have a list of projects [{name, id}] and my model has a projectId property on it (so just the id, not the object).
I can't seem to figure out how I would bind by projectId like I would do with a regular selectbox. All the demos show binding of full objects, but I only need and want the id. I don't want to do anything hacky and modify my model (obviously I can add layers of indirection until this works, but I want to do this the right way).
Related
I'm using a property list in the back office.
I have an image as one of the properties, the problem I have is it only shows the content Id in the property list table, this is a really poor UI experince.
In addition one of the properties are a URL, again instead of showing a friendly URL it shows and internal URL, again not a very good UI experince for a content editor.
Is there a way to change this?
I am new to EPI server and though I have come accross some good features, what is kind of disapoiting are elements of the UI, a property list table like this could look much much better than this.
Can I customise it?
I would like to know how you are Design your Qooxdoo Code.
I don't get the right Architecture which I am satisfied with.
It is hard to encapsulate the View with logic like services.
I hope someone can give me a hint to a Pattern or something to find a good solution.
One of Qooxdoo's greatest features is a strong OO class system, so really the pattern that you use is up to you - MVC, MVVC, etc are all possible because Qooxdoo's OO system provides you the tools to implement your preferred pattern(s).
One pattern that I find very useful, especially in creating larger apps, is to define custom widgets for editing models; for example, if you have models (aka "Business Objects" etc) for Customer, Invoice, InvoiceLine, and Address having a widget for CustomerEditor, InvoiceEditor, InvoiceLineEditor, etc is really useful firstly because it encapsulates the code, but also because it supports binding.
Binding is a very powerful feature of Qooxdoo - to see why, let's assume for a moment that each one of your Editor widgets has a property called value which is the thing being edited.
In simple binding, your editor can bind properties of the model to the widgets which display and edit those properties, eg CustomerEditor bind value.firstName and value.lastName to a couple of qx.ui.form.TextField and automatically changes to the customer's firstName or lastName will be updated in the two TextField's. Binding can work the other way around too, so that changes to the TextField are copied back into the model.
There is a controller class called qx.data.controller.Form that can simplify making this happen, and optionally incorporate validation of user values and user feedback too.
If you have separate Editor widgets, you can also bind to them - for example, Customer could bind value.address to an instance of AddressEditor, and InvoiceEditor could bind the currently selected InvoiceLine to InvoiceLineEditor etc
I would like to add another property like categories in EpiServer. I am already using the categories for something, but I need the same type of functionality for something else. To be able to maintain a list of options in the CMS and give the Editor the possibility to attach them to a block / page. Can someone point me in the right direction.
Unless I'm misunderstanding your question, you could just add another property of type PropertyCategory: http://world.episerver.com/documentation/Class-library/?documentId=cms/9/A942B3E7
It will essentially give you another category selector, in addition to the built-in one.
I have a requirement to display a number of graph/chart "thumbnails". Clicking one will show an "expanded view" (in a separate panel) that displays a larger version of the chart, plus controls to view and manipulate the chart.
There will be a number of different charts, each plotting my data in different ways. Also, a given chart type may appear several times, each plotting a different subset of the data. The controls in the "expanded" view will also differ from one chart type to the next, so there is little commonality here.
I'm struggling to get my head around how to model all this in MVVM, especially given the need to dynamically create an unknown number of thumbnails (and in some cases multiple instances of the same type).
Thinking aloud, I guess I need a view/viewmodel that represents a single thumbnail (the view contains the chart component and the VM exposes the data to plot). I guess I also need a V/VM for the "thumbnail list" UI, responsible for creating the thumbnails and exposing them via a collection for binding to the list. But how does it instantiate these? A VM gets injected into its view, suggesting the "thumbnail list" VM would have to dynamically instantiate the thumbnail views - but a VM shouldn't have knowledge of views should it?!
Lastly, when I display the "expanded" view, it would make sense to (somehow) pass it the charting component/view that was used in the thumbnail, to avoid having to render the chart again, but how?
If it's relevant/helps, I'm using Castle Windsor for dependency injection, and the navigation features of Prism.
This is indeed a complex topic,...
I would suggest a VM for the list of icons not necessarily for the icon itself. this can be bound to properities of the IconListViewModels. Then you should think about a ChartViewModelFactory. Which works in conjunction with your DIC.
An important discussion is the VM-V marriage. View first or View Model first... one way could also be ViewResolver if which returns the matching view based on your view model... this can rely on some sort of conventions. So the final steps could be ask the factory for a view model find the matching view glue them together and bind them to a content presenter...
I hope this helps to get you started...
I wrote my own sub-class, for some selection stuff and paging etc. But those all worked with the renderer(), which required them to return a string.
This worked fine, I created some image-tags and returned those.
But how does this class work in detail?
I want a sub-class which displays a chart in a cell, which should technically be no problem, but the renderer() doesn't seem the right place for it, since it only works for strings.
Does the Class get instantiated for every row? or is it really just one instance for a column, which methods get called for every row with the needed data and the instances don't hold any state about the rows?
The renderer() mechanism is actually implemented in Ext.grid.column.Column, for which there is one per column.
As you have mentioned, the renderer() function returns a string, which could be an HTML string (which could be rather complex - have a look at the templates used by ExtJs for the standard columns). But you cannot return a component (chart).
To the best of my knowledge (based on my own understanding and replies to similar questions), ExtJs does not offer a straight-forward way to render components within grid cells. If you really think about it - you are asking a grid for much more than its intended role. It was designed to present records per raw, with the addition of simple user interaction facilities, like checkboxes.
But what you are really asking for is more of a way to layout charts, for which problem i suggest you look into the Table layout.
Alternatively you should be able to render a chart into a dom element, which will be defined in your own custom column template. But I will consider this to be an involved task.