Creating a totally new form UI

[skyrun]

i want to use fabrik to maintain a (fabrik) list of items (pricing rules in my case). and when i open the form for that item, i present the user with a totally custom ui that can present a more user friendly way than a tradisional 'form' to populate the form data.

i tried using a php list plugin to call the .php script that implments the custom data-input approach, but it seems to run outside of joomla and i can't easily get it to run within to joomla/component framework. i also need to put an 'exit;' on the end or it doesn't show any ui. php list plugins are meant to be run in the background it seems, not to present a ui. which is a good use-case.

so i think the best approach would be to create a custom tmpl that does this. does that sound like the right approach?

 

[cheesegrits]

The 'php' list plugin is a very specific use case, designed to create a custom list button that "does something" within the standard list framework.

The 'php_events' plugin allows you to hang code off of a number of different hooks within the list processing cycle ... like before loading data (usually used to massage the table(s) in some way, like updating from some external source), or after loading the data, or on various ACL related calls (can edit, can delete, etc), yada yada.

The 'php' form plugin again allows you to hang code on a variety of hooks ... before loading data, after loading data, inserting top/middle/bottom content into the form, on submission before processing, on submission after processing to the database, etc etc.

But none of these would by themselves allow you to radically change the UI. They would need to be in conjuction with some template hackery.

Just be aware, as you probably are, that changing the DOM of the form UI has to be done with great care, as much of the element and form Javascript expects a specific DOM structure to work properly. We make liberal use of jQuery's closest('.foo') and Moo's findClassUp() to find things like wrapper divs, and use many of the class names directly to find things. So while it's possible to fairly dramatically alter the look, the underlying way the elements and form is structured in DOM "shape" has to be preserved.

You also have to be careful to make sure that all your elements are on the form (even if hidden), and that all our hidden form data is preserved. Leaving stuff out can have nasty side effects when the data is submitted.

Btw, I'm not sure what you mean by "but it seems to run outside of joomla". I can't offhand think of any of our code that runs outside the J! framework.

-- hugh

 

[skyrun]

Update on this:
First, by outside of the joomla framework, i meant it runs outside of (not within) the joomla template/ui. yes, the joomla framework is there and available, but you can't create output using the php list plugin (not what it was designed to do).

we created a fabrik list (and form) that has meta data about each item (a dynamic pricing grid in our case) like the template name and description and a few other items. we added a list plugin to edit the meta data from the dropdown list on the arrow on the right and set the link in the template name to go to the DETAIL VIEW.

*note we also add buttons to the fabrik lists regularly by adding them to a custom template. the 'import grid' button is an example of that. in our case these buttons usually link to a fabrik form that prompts the user to select something (the grid to import in this case). then the user can press an 'import' button on the fabrik form which runs a php form plugin to perform the action based on the users selections (or return an error). this works very well and we use this model many many places.


then we inserted our code (we used a .js library https://handsontable.com/, but you could use any custom code). in the footer of the detail view template. we have to handle 'save' which takes the data about puts it into a db table we manage. we created the table that holds the data from each cell with fabrik even, but don't use the fabrik form to modify it as it would be a very cumbersome ui editing each one separately.

we could have done the same thing and allowed the user to edit the meta data by putting in the footer of the form vs. the detail viewbut as a design choice. we also wanted to avoid potential conflict with fabrik's data model as hugh points out. so using the detail view makes the other elements read-only when our custom data editing ui is on the page.

here's the result.

hope this helps and inspires someone else to create custom ui's 'under' fabrik's list/form/details framework when the UI requires more than a 1-form-for-1-db-row form can provide.

note that i may have been able to create a custom visulaization that may have been more 'generic', but didn't choose to go that route.