I need to build an application wherein the admin must be able to define forms for data entry. The data to be entered is unknown to me. But the system will need to be able to support all the possible form fields (minus hidden fields, I suppose). So text areas, text fields, radios (with ability to specify what the options are), checkboxes, etc. Also, it needs to be able to support line item entries (similar to EE’s Matrix plugin).
Obviously, I don’t want to try to build this from the ground up. Are there any libraries I can use in CI to make life easier for me?
If none exist, what are some database design patterns I should consider for such a problem?
The best database-design for this is the Entity-Attribute-Value Model. For use with a FORM, essentially your form is the ENTITY, the Attribute will have a type (used for deciding how input will be captured, and data interpreted). Make sure that you index properly.
Remember that you'll only need to data to change the form, don't read from this model everytime you need to show a form. Store a flat file (.json is handy) of the finished form and read that when displaying the form.
Related
I am developing a series of Slack apps for my workspace, and some of them are meant to interact with the content (messages) delivered by the other apps : extracting content IDs that may be referred to by other messages
A concrete example :
Suppose I have an app A "FindUser" that is capable of giving me the user profile when a slack user types find me#example.com, and it replies in the thread with a formatted view of the user profile
I am developing an app B "EditTags", which basically gives me a right click option with "edit tags" (see Slack's Interactive Components/Actions), the idea being that a user could first ask app A to find a user, and then right click on the reply from App A and click the "edit tags" action given by the other app. What this app B does it actually retrieve the tags for the user mentionned by the previous message from app A, and in another reply to the thread it gives some controls to either delete an existing tag OR it shows a select with autocomplete to add new tags.
The B app needs to retrieve the user ID that the A app mentionned previously. So I need some way to pass that data directly in the slack message. When looking at the examples, slack does not seem to provide a way to add arbitrary "metadata" to a message, am I wrong ? Do you have workaround for this ? I mean I could totally send the user ID say, in the footer, so I can just read the footer, but I was planning to use the footer for something else... Is there a way to pass metadata hrough properties that would be hidden to the end user ?
Although this does not feel relevant, I am building a slack nodeJS app using the node slack sdk (and especially the #slack/interactive-messages package)
For the most part the Slack API does not provide any official means to attach custom data / meta data to messages. But with some simple "hacks" it is still possible. Here is how:
Approach
The basic approach is to use an existing field of the message as container for your data. Obviously you want to pick a field that is not directly linked to Slack functionality.
Some field are not always needed, so you can just use that field as data container. Or if its needed, you can include the functional value of that field along with your custom data in the data container.
For example for message buttons you could use the value field of a button and structure your code in a way that you do not need it in its original function. Usually its sufficient to know which button the user client (via the name field), so the value field is free to be used for your custom data. Or you can include the functional value of your button along with the custom data in a data container (e.g. a JSON string) in that field.
Serialization
All messages are transported through HTTP and mostly encoded as UTF-8 in JSON. So you want to serialize / de-serialize your data accordingly, especially if its binary data. If possible I would recommend to use JSON.
Length
The maximum allowed length of most fields is documented in the official Slack API documentation. e.g. for the value field for message buttons can contain up to 2.000 characters. Keep in mind that you need to consider the length of your data after serialization. e.g. if you convert binary data into Base64 so it can be transported with HTTP you will end up with about 1.33 characters for every byte.
Contents
In general I would recommend to keep your data container as small as possible and not include the actual data, but only IDs. Here are two common approaches:
Include IDs of your data objects and load the actual objects
from a data store when the request is later processed.
Include the ID of server session and when processing the request you
can restore the corresponding server session which contains all data
objects.
In addition you might need to include functional values so that the functionality of the field you are using still works (e.g. value of a menu option, see below)
Implementation
Dialogs
Dialogs provide an official field for custom data called state. Up to 3.000 characters.
Message buttons
For Message buttons you can use the message action fields / value. Up to 2.000 characters. Its also possible to use the name field, but I would advise against it, because the maximum allowed length of that field is not documented.
Message menus
For Message menus you can use the value field of an option or the name field of the menu action.
Usually the value field is the better approach, since you have a documented max length of 2.000 and it gives you more flexibility. However, you will need to combine you custom data with the actual functional value for each option. Also, this will not work for dynamic select elements (like users), where you can not control the value field.
When using the name field note, keep in mind that the maximum allowed length of name is not documented, so you want to keep you data as short as possible. Also, if you want to use more than one menu per attachment you need to include the actual name of the menu into your data container.
Normal message attachments
Normal message attachments do not contain any suitable field to be used as container for custom data, since all fields are linked to Slack functionality.
Technically you could use the fallback field, but only if you are 100% sure that your app is never used on a client that can not display attachments. Otherwise your data will be displayed to the user.
this question might be a bit special. I am using this Joomla 2.5 extensions to give authors the abilty to add Attachments to articles: Joomla Attachments
The extension renders an input field called "description" in a backend form to insert an file description for the provided file. Unfortunately it´s not taking HTML tags which I need. By saving the form it seems a strip_tags() or preg_replace() or something similar cleans the input. I combed through the code of the attachments extension but couldn´t find a place where the input is cleaned or saved.
To hopefully stay in the Question + Answer rule of Stackoverflow:
Is there a class which extensions inherit from the Joomla Core to save form data to a DB-table ( which also could be responsible to clean and validate user input )?
thanks for any idea,
tony
You should see how the field is defined first:
1. Form definition
look into the
administrator/component/yourcomponent/models/forms/somename.xml
there you could find a form definition, if so it will also specify the field type: depending on the type there are several available filters; for example the default textarea will strip html, and you need to set
filter="raw"
in order to enable it. see http://docs.joomla.org/Standard_form_field_and_parameter_types for a list of fields, click and you can find the available format options.
2. model
If the model inherits from JModelAdmin or JModelForm or other JModel* it will automatically handle binding of the forms' data to the database, look for the Save function which should receive the form $data.
3. more
There are at least another dozen possibilities. If the above didn't help, try finding the form: possibly you could find it just by looking at the markup. Once you have the form, check the following fields:
option
task
view
This should help you find the php code that is invoked based on the form:
if view is set, maybe in ./views/someview/view.html.php you could find the saving logic.
if task is set, look for a function with the same name in ./controller.php
if task contains a ".", look for the controller in the ./controllers/ folder.
if option is not the name of your component, your component is sending the data to another component for saving, and most likely set a return-url
everyone!
At first, I made a single form with large amount of elements: text fields, text areas and so on. When I had got the form ready, I understood that it is not so user-friendly to have such a large form to be filled-in in a row. I don't want to use the "step" system (step 1 -> step 2 -> ... -> step n), because I want for the end-user to be able to have this form filled in any order (+ User would be able to see beforehead what forms he would need to fill), so I divided the form into the several tabs.
The idea is following: once user has filled the form in some tab, he hits the "Save" button and proceeds to the next one (in arbitrary order of his choice).
The thing I wanted to know - what would be the best approach to store the intermediate data ? Should I have some hidden input for each of the tab forms with tab-id to be passed to the model, so that at each 'step' only tab relevant data was validated and stored in DB. Or, maybe, I should have a session[:object] that would contain the current object and at the very end I would store it in DB and erase from the session.
Can this idea be realised ?
Thanks in advance! :)
there's a gem called wicked, it allows you create wizards in a very simple way, check it out
I'm not a ruby ninja, but in other languages (like php) we usually use sessions to do this. Why not to do this on rails?
Also you can consider creating a table for "temporary storage rows" in addition of using sessions, so every time you change the page you could save the data to that table and, at the end, save them all to your main tables.
This is useful if you usually loose your session... you can related the temporary storage rows with the user and if he looses the session, you can restore his uncompleted forms from your database.
You could simply go the Railscasts 217 - Multistep form approach, which works fine.
However, this may not suit you as you may only store the data AFTER you have everything collected, and not step by step.
Another solution - as you mentioned - would be using e.g. jQuery tabs to create your form steps and building a little validation via AJAX / backbone.js before storing the actual record with all its data.
What is the standard convention to save data in textboxes and other form data to be loaded the next time the program is opened?
I personally do not know of any convention, however you could look into the following methods:
Using the registry: http://radio-weblogs.com/0111551/stories/2002/10/14/registryRwInC.html
Using profile strings: http://dotnet-snippets.com/dns/c-read-and-write-ini-files-SID574.aspx
Not sure of the standard convention, or if there is one, but saving to a text file would be a simple-to-implement solution.
It depends on the kind of data that you are trying to save. If this is a relatively small amount of user specific data associated with their user preferences, then user settings are the way to go.
If this is large amount of application data (for example like an entire address book), then you are probably better off writing to an external file or database in whatever format suits your needs.
You should be looking at Windows Forms data binding - that is the best way to save data from and reload data into a Windows Forms application. Once you have set up your form controls for data binding, you have a choice of where to store the data, as explained here.
I've been having a look at several MVC frameworks (like rails, merb, cakephp, codeignitier, and similars...)
All the samples I've seen are basically plain and simple CRUD pages, carrying all the infr needed in the querystring and the posted field values.
I've got a couple of apps made with some sort of framework built with classic asp.
This framework handles some CRUD stuff a little more complex than the examples I found.
Something like master-detail, filtering by example, paging, sorting and similars.
I have a controller class that it's just a finite state machine, that goes thru diferent states (like new, browse, filter, show, etc.), then performs the appropiate action depending on the event raised and finally retrieves the neede info to the calling page.
To achieve this I have several hidden inputs to keep the state of the web page (like current id, filter criterias, order criterias, previous state, previous event, well, you get the idea)
What do you think would be the finnest approach to achieve this kind of funcionality?
hidden inputs built in the view and used from the controller??? (I guess that would be the equivalent of what I'm doing right now in classi asp)
--
(added in response to tvanfosson)
basically, my question refers to the third category, the context-dependent setting (in respect to the other two categories I agree with you) the info I was storing in hidden fields to store them on the querystring, I guess that when you click on the "next page" you include everything you need to save in the querystring, right? so that piece of query string gets appended in each and every link that performns some kind of action...
I'm not sure, what are the advantages and disadvantages of using the querystring instead of hidden inputs???
I use different strategies depending on the character of the actual data. Things that are preferences, like default page size, I keep in a Preferences object (table) that is associated with the current logged in user and retrieve from there when needed.
Persistent settings associated with the current logon, like filter settings for a page, are stored in the user's session. Generally these are things that if a user sets them in the current session they should remain sticky. I think filter settings and visibility are like this. If I filter a list, navigate away from it to drill down into a particular item, then come back to the list, I want my filter settings to be reapplied -- so I make it part of the session.
Context-dependent settings -- like the current sort column or page number, are controlled using query parameters. Paging and sort controls (links) are built with the appropriate query parameters to "do the right thing" when clicked and pass any necessary query parameters to maintain or update the current context of the control. Using the query parameters allows you to use an HTTP GET, which is bookmarkable, rather than a POST. Using hidden form parameters makes it much harder for the user to save or enter a URL that takes them directly where they want to go. This is probably more useful for sorting than it is for paging, but the principle applies equally.