I want to develop a simple app with a few screens:
List of items that user can select. (7 items)
Sub-list of items based on the value selected in the first screen (another 5+ items for every 7 items from the first screen)
Simple screen showing some strings and two images based on the value selected in the second screen.
What is the best way of defining those values in terms of Flutter best practices?
Right now I have a list of strings in my main.dart (first screen):
List<String> menuItems = <String>[ "Item 1", "Item 2", "Item 3" ];
When one of the items is pressed by the user, index of the selected ListTile is passed to the second screen (list_screen.dart).
And now I don't know what is a best way to go from here. Should I declare 7 lists in that file for every item that can be selected in the first screen? And then in the third screen declare next lists for both strings and images? This seems like a mess and will result in long files with the actual widget declarations preceded by a huge number of list variables.
Or is there a better way to store the structure for that kind of app? In Android native I was doing that using arrays in .xml files. Maybe creating separate .dart files for every screen's data is the right way?
I suggest learning about State management (bloc, Cubit, Provider) those are the top 3 libraries, I like cubit because it is simple and straightforward, now, storing variables can be done in 2 different ways, you can store them in XML or JSON file and set it ina assets older, then you parse the data in the controller class. or, you can store them as lists in the controller (cubit file) and let the three screens read from this cubit file and react to the changes made by the controller. you can use a local database also.
I hope I answered your question .
Related
I'm working on a GUI based on wxpython and have the following question regarding wx.Combobox feature:
Is it possible to display dict.values() in the drop down list and select one of the displayed item but in Bind event send dict.key for this item somehow? I want to present possible options for selection in a user friendly way - example is below.
I think it should be possible with the dictionary but don't know how to realize that.
I'm parsing all Sections from INI file with configparser to a list:
sections= ['123ABC456','123DEF456','123GHI456','123JKL456','123MNO456']
and assign it to Combobox:
self.combo_sections = wx.ComboBox(panel, choices=sections)
self.combo_sections.Bind(wx.EVT_COMBOBOX, self.on_combo_sections)
self.on_combo_sections function is parsing section's options.
What i need is to convert list items to a readable format:
['ABC','DEF','GHI','JKL','MNO']
And display these values under combobox drop down list. Since initial Section's values are essential for further work - based on section name, configparser gets section's options, how can i send original values instead of formatted ones but still display formatted ones under the drop down?
Thanks in advance for any inputs!
wxComboBox supports associating the so called "client data" with each of its items, so you can use this and store the sections value as this client data, then you will be able to get them back whenever you have an index of combobox item.
Alternatively, just keep your own array in combobox items order and store the sections in it -- this is more or less how "client data" is implemented internally anyhow.
The main advantage of using built-in client data support is that it is kept in sync even if the items are added/inserted/deleted to/from the control, but if your combobox doesn't change after creation, using your own data structure should be simpler.
I'm trying to create a flat view that shows all documents in a list without folders, but I can't figure out how to get for each document the columns of the parent folder.
We have to keep the folders system, but be able to use filters on this view.
View screenshot with folders
View Screenshot without folders, where I need to get the folder columns
I think this is a misunderstanding of the columns behavior, in fact you are displaying the same columns in both views (except for Modified, Index, ISO Language), however I assume what you really want is to display the same Field Values of the parent folder for each child item, that kind of behavior (values inheritance between folders and child items) isn't possible by just editing the view neither by applying some list settings.
First of all you need to understand that list items, documents and folders are all list items from the system perspective so they have individual properties for each one of them, a folder is just a special type of item that is able to contain other items (strictly speaking is just simulating a container).
In your case the Field Values that are being displayed in the columns of the folders view are values that belong to the folder itself but not to his child items. If you want to propagate those field values for the child items of each folder then you have two options:
Manually: Assign the values to each child item by editing their
properties using the Edit Form or using a Grid View to edit multiple
items faster.
Automatically: Create a Workflow or Event Receiver to copy the values
of the parent folder to each new item/document that is added to the
list/library.
However, as I can see your library is not being used in production yet, so my personal recommendation is to change your approach and use something similar to a Managed Metadata term store instead of folders (folders should be your last option to categorize items/documents, just for cases when you really don't have another way to achieve your goal), with the Managed Metadata approach you are able to apply tags to the items allowing them to belong to multiple categories and being filtered and searched more efficiently, but I know what you may be thinking "how can I do this if the Managed Metadata Service is not available in SharePoint Foundation", well thats why I said "use something similar", there should be more than one third party solution out there that will provide a similar functionality, but if you want to choose the less effort path, just use out-of-the-box Multi-choice field or Multi-lookup field, that you can start to using right now and assign the categories that you want to your items and create different views and filter them.
To achieve this you need to create a new view, or modify an already existing one, in your library.
When you edit or create a new view you are presented with the "Edit view" screen, here you can choose to "Show all files without folders" in the "Folders" section.
See e.g. for more details http://www.bloggedbychris.com/2013/10/19/flatten-document-library-list-sharepoint-2013-2010/ on this particular problem.
I have a SharePoint list that has MANY columns in it. The default AddForm and EditForm rendering is very cumbersome for the users. Most of these fields hold simple Number (integer) values. The default rendering for those two forms (using the ListFieldIterator I suppose) render the columns one by one vertically down the page. My thought was to design an input form with three basic "zones" (left/middle/right) and use a Custom Field for all of these "Number" fields. The Custom Field would contain two custom variable properties "Zone" and "Order". (Zone could contain middle/right and order would be the "order" in that zone the field would appear, the "left" zone would be for the fields that are not these "Number" fields, things like Date, Customer, etc. etc.) I would design the page with an HTML table and 6 Columns (1 for the "label" and one for the "TextBox" for each of the three "zones"). Then I could put a control (something similar to the "ListFieldIterator"). The control in the first zone would render the "static" fields, the zones in the other two zones would render the appropriate Custom Fields (based on the Custom Variable Property "Zone" and "Order").
Does this make sense? For the life of me, I can't figure out how to do this. I had thought about "giving up" and just using my ASP .Net skillset and creating FormViews and GridViews bound to the proper (ListView) DataSources. That has even proved challenging.
Does anyone have any ideas on how I could accomplish this? (InfoPath isn't an option and I want to stay with the "Custom Field" idea so the fields aren't laid out statically and can be moved around or even new ones added by the "administrator" of the Application (SharePoint List).
Any guidance is MUCH appreciated. I have been working on this all week and just seem "stuck".
Thanks,
Shayne
------ A Better explanation of my "application" and what I want to do-----
I have a SharePoint List that has about 60 fields in it. If I pushed this application out using the default Add/Edit SharePoint List Forms (and Rendering Templates), the users would hate it. The default forms use a rendering template that basically lays out all the list fields, one per (HTML) Row. Within that Row there are two (HTML) columns. The first one contains the "Label" for the field, and the second (HTML) column is the actual editor for the "FormField" (Text Box or whatever). Because of the number of fields in the list, the user would have to scroll several pages just to get to the bottom.
This list has about 10 "static fields" that I want to lay out on the left side of the page and then about 50 that are simply "task" fields. These store an integer and track "how many of these tasks did I do today". (This is a "port" of an MS Access application.) Depending on the "Add" page the user selects (I have a "parent" content type that contains every field and then a "child" content type for each "group" of users that will be using this form that contains just the fields/tasks that group tracks) the proper fields are rendered on the page. The problem is they are all rendered vertically and there is too much scrolling. These users (and admins) will NOT have access to SharePoint Designer or InfoPath. So, the "layout" for these fields must be iterator/repeater style (the users shouldn't have to get Development involved just to add a new "task" field to their application!).
The solution I had come up with is to use a Custom Field Type with two Custom Property Variables for each of these "task" fields. The Custom Property Variables (Zone and Order) would allow the administrators of the "application" to control where they want these fields to appear on the Add and Edit forms. The Zone Property can contain one of two values: "1st Task Column" (middle of the form) or "2nd Task Column" (right part of the form). (The "left" column of the forms would be used for those 10 or so "static" fields that all groups/depts/content types share.)The Order would just contain the order to sort the fields in, within their "zone". Obviously, the "zone" would indicate where on the form the field would appear (middle or right). I thought I might be able to use three Divs and render the appropriate List Columns in the appropriate DIVS. Or, following the default rendering template, instad of DIVs I could possibly use 6 (HTML) Columns instead of 2.
I quickly figured out how to make a new Field Type with Custom Properties (I used the Property Schema element in the XML definition, even though Microsoft says NOT to use that in SharePoint 2010, it was just so easy and I couldn't figure out how to add them otherwise. Now I know how to add them the "right" way, I just don't know if it is worth changing them.)
For the last few days, I have tried to figure out how to actually render these "zones". Remember, I want the users of this application to be able to add new fields dynamically, so I can't put any static field references in these forms. I have read about the Rendering Templates and the ListFieldIterator (and the new Content Iterator), but I can't seem to pull it all together and create an actual solution. The part that is throwing me off is how to query and render three different "sets" of fields at once (since the rendering is going to happen from "top to bottom").
Any help is very much appreciated!
Shayne
If InfoPath it out and you want to stay within the SharePoint infrastructure for forms, then the term you need to search for is DataFormWebPart. You may have heard of DataViewWebPart before, well this is the form equivalent. Just like the DVWP, this does lots and lots of XSLT to make its magic happen.
The trick is can you implement your grid/zone idea within the context of the DFWP's XSL. That I can't tell you but hopefully this is a starting point.
Defiantly Info Path is the solution here are some tutorials:
Video: http://channel9.msdn.com/blogs/laurhar/infopath-2010-customize-a-sharepoint-list-form
http://p2p.wrox.com/content/articles/customizing-sharepoint-2010-list-forms-infopath-2010
http://blog.libinuko.com/2010/03/21/sharepoint-2010-howto-start-customize-list-form-neweditview-using-infopath-designer-2010/
if you don't want to use InfoPath I would recomment JavaScript/jQuery you have just to modify (Edit) the page then inject some jQuery code to do what you want. Here are some articles about similar topics:
http://akanoongo.blogspot.com/2008/04/how-to-hide-fields-in-sharepoint-list.html
http://spground0.blogspot.com/2011/03/sharepoint-2010-custom-list-form-issues.html
http://ghamson.wordpress.com/2011/01/19/using-jquery-to-attach-regular-expression-validation-to-a-sharepoint-list-form-field-sp2010-ps2010-projectserver-in/
The only way you can achieve this type of custom form designing within the SharePoint framework is to apply it through post-rendering techniques using client-side code. And solutions like this tend to add considerably to page-load.
Simply changing the render template is not enough if you want it to be a dynamic and codeless experience for end users to author.
I can think of only one solution which comes close to fitting all criteria. It's "free", can be password protected, and also allows tab groups, rules and many other settings.
Dynamic Forms For SharePoint - http://spjsblog.com/dffs
I am appending 20 images in form by using loop.when i am scrolling these images up and down i want selected image index so that i can view bigger size of selected image.
i used this form.append(image)
is there any method or way to get selected item index in form like in list there is getSelectedIndex.
plz help me and provide me gud solution ..
The APIs for javax.microedition.lcdui.Form don't provide a means to get the selected item index, most likely because it wasn't designed for that kind of use. For the use case as described in your question, the correct approach would be to use javax.microedition.lcdui.List. In addition to determining the selected item, List also provides other useful APIs such as setting a select screen command for the items in the list.
I am creating a gallery/albums site in Drupal 6.
Perhaps the description will be a bit detailed, but still on some reason it's a problem to create a gallery in Drupal in a simple way.
As for now I am using CCK + Views + FileField + ImageCache + Lightbox2 combination.
This has allowed me to
- create Album CCK node type that can hold multiple images
- create a view that displays Albums in 9x9 fashion (using pager and items per row)
But here is one problem. While the main 9x9 view with albums displays nicely, when I drill down into particular Album node by clicking it's picture, it displays the uploaded node images in a vertical row and I am unable to control it's formatting.
Apparently, I have 2 options
a) to somehow control the html output of my CCK field with its files (to divide into rows)
b) or to create another view to display pictures from one album
As for now, I am not sure which of these two ways is the best and what specifically I need to do.
a) I can create node-album.tpl file - but all its content will already be in a single $content variable, which I don't be able to break into 3 items in a row. Am I wrong?
b) if I decide to create a view to display items from a single Album node, I am not sure how I reference it from the parent Albums view. The problem is that in view's Fields section I am able to override the Link, but it offers only 2 replacement patterns to pass to a potential "child" view, which are [title] and [field_images_fid] - is that enough to create a child view to show images from a specific album?
I just recorded a screencast outlining one approach. There's quite a bit of discussion in the comment threads about alternative methods; I'd definitely suggest using Views Attach if you want more control over the presentation of the gallery itself.
I can create node-album.tpl file - but all its content will already be in a single $content variable, which I don't be able to break into 3 items in a row. Am I wrong?
You are right and wrong.
In your template.php file you can pass other variables into your node-album.tpl, you could pass in the $node variable and display in a very customised way, although this will remove flexibility later on, as if you use another module to add things to $content you will have to edit the tpl file to access new variables.
To do this you use the preprocess_page hook in the template.php file. You can add variables to the $vars array and use these in the node-album.tpl file. I think that $node will already be defined in the tpl file, which will probably make your life easier. you can disregard content altogether.
If this doesn’t work for you, you can also create a custom module and use hook_nodeapi and hook_theme to theme things any way you like, while still using $content. However this may be a bit too much work for you needs (if you want to go this way, reply and I'll write a separate answer).