How can multiple users work on same project / same form at a time?
Something like a repository.
In our project there are multiple sections & work is divided on these sections. We tried to save the same form from different systems but form saves only recent data (recently saved form).
Is there a method to club or merge code?
At this point, Orbeon Forms and Form Runner don't support multiple users editing exactly the same form data. Of course, multiple users can at the same time edit multiple "instances" (form data) of the same "form" (form definition).
So, I would, if possible in your case, restructure the form, maybe splitting it into multiple forms, to avoid that situation.
After researching I found an alternative.
We are team of 4 & we spitted our work based on the Sections. Make sure that each developer should have Unique Section.
Go through the Orbeon Source & Collapse XML Tags shown in Image.
after doing this your code should look like above.
Point #1: Copy your other sections here
Point #2: Copy your Binding Code.
Point #3: Copy your Services & Actions
Point #4: Copy your form sections.
This is how we merged 4 different application.
Few things to be checked
Repeated Grid
Actions
Services
All the best! Happy Coding :)
Using Git, each user can work on their own copy of a form, regularly committing changes and pushing to the main branch. Occasionally there will be merge conflicts, but if each user only updates a specific section then conflicts should be get to a minimum and not too complex.
Orbeon persistence can also be configured so that form code can be saved directly to text files.
Related
A website I am currently developing with Neos / Flow includes a self-developed shop system implemented as a Flow Plugin. The products, variants and vouchers are kept as domain models.
Since the customer wants to provide their website in different languages I need to find a way to manage translations for the domain objects.
I cannot find a way which is baked into Neos/Flow so my first thought was to simply insert translation identifiers inside the translatable fields (description & stuff like that) which are then used inside the view with the translation viewhelper. This would work totally fine if the customer would not want to edit those fields by themselves.
My next idea was to just implement an extra field for each language-dimension and each translatable field (like description_en; description_es, …). But this would be the worst approach in terms of maintainability and changeability.
I usually worked on TYPO3 projects where translation of domain objects is really easy and working out of the box. So this experience inside Neos is very frustrating.
Does anybody came across a similar problem or even has found a solution to this?
whenever we've got the requirement to have multi-language content so far, we've solved that, by storing the data within the Neos Content Repository. This way language handling aka dimensions work out of the box. Also, building a UI for that records is very easy by using inline editing or the inspector of the content module.
Note, that storing data in the CR does not necessarily means, that you have to store it under the /site root node. You could also add a new root node /products to store your products.
You could have a look at https://github.com/neos/metadata-contentrepositoryadapter where meta data is stored under its own root.
Hope that helps,
Cheers, Daniel
For the record, something like that could also be achieved with the Doctrine Translateable extension in pure Flow:
https://github.com/Atlantic18/DoctrineExtensions/blob/master/doc/translatable.md
See http://flowframework.readthedocs.io/en/stable/TheDefinitiveGuide/PartIII/Persistence.html#on-the-doctrine-event-system on how to activate the extension in Flow.
However, the cleaner aproach indeed is to actually separate domain model and content (unless you build a CMS and the content is your domain ;)
On the saving of Case record I want to assign the case to respective Agent based on case type , sub type and Client/Account,
I have a Assignee field on Account form which I need to get the Agent's name to Assign the case.
I am creating a custom workflow activity for that, but while writing it I stuck how to fetch Case forms record on which I apply logic.
Please suggest what is the good approach, do I need to make a retrieve call to fetch these parameters or something else.
While setting the Custom Step Input Properties drop down fields are not populating to select the Dynamics Values.
Better to use plugin, as the documented/supported preimage is available in plugin steps + flexible.
You have to look for type, subtype, etc in target entity (incident in your case) or preimage if needed to apply logic.
If you still want to use workflow, go ahead & follow this article.
we can always read Pre image and Post image in the plug-in for various purpose. However, in workflow, we may sometimes want to read Pre Image for some purpose. Now we can also read Pre Images and Post Images in the workflow using Execution Context. It uses the same Plug-in Architecture and hence we can use it to read Pre Images and Post Images. However, this concept is not documented in the SDK so it might be unsupported.
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.
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.
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.