I am trying to have a table like view for my component, however I don't want to use the table component. Since, the table will save the data as html with tags and its difficult for me to read the data inside the rows. Traversing through or and so on.
If not, I was thinking to have a multifield component, which has one set header (for table header row) and the rest of the fields below will be mutlifield, we can keep adding as many rows as we want.
At present, i have something like
Name - value
Path - value
Type - value
The above entire thing is one value in the mutltifield. I can add multiple fields like the above.
but the ui looks clunky if we do it this way. I'd rather have a table like format.
if anyone has any suggestions I'm open to them.
Thanks
Your best bet will be to use CSS to override the look and feel for your custom multi-field and AEM's multi-field management UI.
You can probably make it look and feel like a fluent grid by changing the spacing between the edit fields and dimming the borders.
Making one monolithic custom extension to look and feel like a grid/table will be too complex and introduces the risk of deviating from node structure so I won't recommend that unless you are planning to take over the component's properties dialogues in authoring mode.
Related
Is anyone aware of any means to test if a View, Table or Filter is part of the 'Built-in' set?
I can't see nor find any obvious way of doing this so will build some collections that hold the names of these items so that i can avoid these in code, but it feels like there should be a property that identifies these..............
There is no "built-in" property.
Furthermore, Views, Tables, and Filters can be modified and/or deleted by the user so even if you find a view called "Gantt Chart" it may not resemble the standard (default) view. You can build a list of view names, but don't count on one in a user's file being the same as in any other file.
I need to create a system to store and serve information about survey questions. Given a variety of questions, field types and field arrangments, I need to serve the data needed by the front end to display the fields.
One of my big concerns is layout information. I'm not sure all the ways the fields can be arranged. At a minimum, I need to support things like two text fields appearing on 1 line, with a third on the next line. Or 6 multiple choice answers arranged in 2 columns of 3 rows.
Is it appropriate to store this layout information in my database, and to serve it with the question/field data? I think these are my 3 options. Any thoughts on these options would be very helpful, or suggestions for other things to consider:
I could store indicators that the question uses a column layout, and give each field hints as to what row/column it is in.
I could store something like CSS or mustache templates to define the layout.
I could leave this entirely to the front end. I could return the survey data and expect the front end to handle any layout concerns
The general answer/advice i would give is no. If you put any layout information in the database you will make it very hard to build new functionality, extend your product offering in the future, support multiple front ends (mobile, progressive web app, main website) and perform redesigns in the future.
I would go with option C. Leave it to the front end. You can easily store the 'type' of question which may map to a template in the front end maybe, this will allow the different front ends to render that type of template as the design needs. And will allow you to easily evolve the design in the future, the last thing you want if you desire to do a redesign is to need DB update scripts to try and 'fix' css and display data.
Obviously i lack the full picture of what you are trying to achieve, the road map of your product and your future ideas, but i honestly cant think of a scenario where storing css in the DB would be a good idea.
I hope you find this useful, I would be keen to hear how you decide to progress with this.
I'm interested in displaying 1-5 model instances using forms on a page using a grid similar to something one would find in a desktop database application. I understand I would need to use multiple forms or formsets but an additional requirement is that I'd prefer it to be in more of a grid format with each model's fields being display in columns with common field labels on the y-axis.
I should have the ability to edit multiple columns (so in effect, model instances) at the same time and then commit either the single column (model instance) or commit all. I'd also like to be able to highlight the changed cells that have changed to give visual feedback to the user that there are pending changes.
Sorry for the rather long list of requirements and I'm aware this probably requires a few different technologies/techniques to achieve. I'm throwing this out there because I'm asking this kind community for guidance on what components/technologies I should look at. If luck would have it, there would be some jQuery component that can handle this for me almost out of the box. If not, some guidance on achieving the editing of multiple model instances would be of help.
I will also need to build in versioning in case the data displayed on the view page is stale and to prevent overwriting a newer commit. I'd probably achieve the latter using a versioning field in the table that will perform the check and handle it accordingly.
Also, Flask and Django are both options for the engine and WTForms look to be promising at least at first look.
Thanks
There is no such ready to use solution in Django. Just create your custom form that handles as many instances as you want and do anything that you want, or extend formset.
I'm trying to tie django-mptt and contrib.admin together by providing something friendlier than a flat list in the admin. Because the trees are supposed to be large (otherwise i wouldn't be using nested sets), users should be able to expand and collapse parts of it.
When a user expands or collapses or expands a branch (ajax is used for that), a cookie is also set containing a comma separated list of collapsed branches. This way, next time this user visits the admin for my django-mptt powered model, i can show him the tree in the exact state he left it. Now i would like to use this list of collapsed branches to ease the burden on my database by fetching only needed parts of the tree.
Is there a way to do this effectively? The solutions i googled were making a query for each branch so they could avoid querying when a branch was collapsed, but that doesn't look very effective to me. Maybe it is possible with a fixed number of queries?
You're not really explaining what you're doing, so it's a bit hard to help. (What are you doing with the tree? How are you displaying it? What do you want the users to be able to do?)
Each element in a Django-MPTT tree has a get_children() method - and using the optional include_self=True parameter you can get a list of the element and all its children. You can use this to pre-filter subtrees so that you only display parts of it, if that's what you want.
If you want users to be able to dynamically expand and collapse parts of the tree without reloading the page, you will need to use AJAX. There are various AJAX-enabled treeview controls around - I've written one myself using jQuery - and no doubt one of them will do something along the lines of what you want.
I've got a wxGrid that I populate dynamically. I'd like to store some information with each row that shouldn't be displayed to the user. What is the best way to associate data with a row? Should I just create a hidden column or is there a better way?
Creating a hidden column is the fastest, but indeed a very ugly method. If you can justify the effort, then you should better create your own grid table base class. Your own wxGridTableBase-derived class can hold any information you need it to, without the need to show it in the grid. Unfortunately the documentation for that class is sparse or nearly non-existent.
For an example see the grid demo in the wxWidgets samples directory, specifically the BugsGridTable class. What you will notice is that you do not necessarily store the strings that the grid will display, but you can format your data in the GetValue() method. This can be a lot better, both in terms of memory consumption, and because you can change the format of displayed data on-the-fly.
The switch to a custom grid table base class has had a big impact on speed, memory consumption and functionality for the result set data grid of FlameRobin, an administration tool for the Firebird relational database. You can always check out its source code for how we use wxGrid.
Store the value in the row label using SetRowLabelValue and hide the row labels.