15 replies to this topic

[Marcher Technologies]

As per the blog entry comments.... it would be IMMENSELY helpful to have the ability to define what submission template a database or database category uses.
For many, many reasons, not least of which is not having to revamp the content skin templates immensely just to hide a single field that should be admin-only.
Or a field used in one category.... or a dynamic form based on multiple fields using js show/hide... which I've done, but is a hassle with the system as it is now.
or say for example, i need to check an input for an acceptable value beyond what the usual validators allow on a text input.... based on another fields value in that form....
Basically, as it stands, there is no feasible way to prepackage a custom content database submission form...... which really needs to change.

[arikbo]

Awhile back I asked if it was possible to have permissions on fields. I got confused by the "Allow User Editing". I thought perhaps it would only be available to admins. I have a couple fields that I would love to have admin only so, yes! +1

[Tigratrus]

Totally agree.

As sometimes an example of real wold usage can illustrate a need better than a simple description of the need I submit the following:

We're building a system where people submit their home renovation projects by creating an entry in a custom IP.C database.
There will be separate categories for the different (functional) rooms in the house; Kitchen, Bathroom, Living Room, Bedroom, Dining Room, Childrens Room, Office etc.

Now many of those rooms will have data fields that they have in common:

Cost of renovation
Time involved
Whether it was DIY or Professional
Type of flooring
Decorating Style (Modern, Traditional, Coastal, Art Nouveau etc)

Some groups of rooms will share data elements that are common to them, but do not exist in others, for instance both Bathrooms and Kitchens will have Faucet and Sink info, but a bedroom or Home Office will not.

However many of them will have data entry requirements that are unique to that particular space:

Kitchen:

Gas or Electric Range
What type of Countertops
Cabinet Doorstyle
Whether there is an island or not
etc
etc

Bathroom:

Full or 1/2 bath
What type of Tub
Shower type
Toilet make/model
etc

Home Office:

Number of people who work there
What type of business is conducted
etc

Now when you add up ALL these various fields for ALL the rooms it comes to a total of well over 100 fields. But when submitting an entry for a Living Room remodel, it would be a horrible user experience to present the member/author with a huge scrolling list of fields that have nothing whatsoever to do with their particular submission. As good web designers we also have a focus on crafting the data entry experience so that the form is laid out for good usability and intuitive use, and not just as a single column of identically styled entry fields. All the entries need to be in a single DB not individual DBs for each room type for a multitude of reasons, not the least of which is that people will be running searches to see ALL rooms where a given product, floor type etc are used.

There's a nearly infinite number of reasons why you would want to customize the entry form on a per category basis.

James
(of James and Susan)

[Tigratrus]

Susan pointed out that it would be good to use a totally different type of example to illustrate the point as well.

So to give some other examples, consider:

An RV database:

RVs and Travel trailers would both have a huge number of things in common, but RV's would have have a lot of unique data fields that have no applicability (Engine, Milage, Tank capacity etc) that travel trailers would not.

Motor vehicles database

There would be many fields in common between cars, motor cycles and trucks but many fields unique to each as well.

A Paid directory system (there are a ton of these out there and many make good money) that covers anything from types of doctors to renovation contractors to parts suppliers etc.

I can come up with literally hundreds of examples, along with real world sites where they are in use. Buuuuuut it's almost dinner time!

James
(of James and Susan)

[bfarber]

In reading this, there are a few ways we could go here.

1) We could allow you optionally link a custom template so you can craft the submission form manually. This gives a lot of flexibility, of course, but has the downside of requiring a LOT more work on your part. Then again, it can be optional, so the average user can use the existing submission form, but users with more advanced needs could link a custom submission template.

2) I tend to think this might be a better and more useful approach...we could overhaul fields to support many of these missing functionalities you are looking for.

• Allow fields to only be accepted in specific categories
• Allow fields to show or hide based on values in other fields
• Allow field permissions (i.e. only show a field if you are an admin, or a guest, etc.)
• Perhaps implement custom front-end validators. We have backend validators, but I can see value in allowing front-end validation too (javascript checks before form is submitted)

3) We could look into implementing both, but I'm not sure how much #1 would really be used if fields were fleshed out more and had the capabilities you are really after?


I should note that all of the above are relatively invasive and big changes that aren't likely to make it into 2.3, but I'd like to discuss these ideas further for planning future releases. I think there's some value in the ideas here.

[mat206]

The two biggest features you could possibly add for ease of use would be form customizations and portability of everything.. that is, the ability to package up databases, blocks, and templates for easy distribution or even movement between a development server and a production server. It also makes it possible for us grunts to start sharing some IP.Content love and create 'apps' for people.

But to the point, option #2 sounds like a ton of work on your part. Ultimately IP.Content is not your run of the mill CMS.. you provide more of a framework for people to build off of. I think what #2 describes is largely going to be used by powerusers.. the same people who can put together a form anyway. But if you force us to use a pre-defined template for forms, you take away the flexibliity that you created with the whole IP.Content concept. It's unlike your standard CMS, so stick with that mantra.. because it is better.

Right now we know that form data is getting passed to a skin template.. it's just that the template doesn't do anything pretty with the ordering or formatting of the form. *THAT* template could serve as the default form template in the template editor. I think even if you did a solid job on #2 people are still going to want to format their forms in a custom way. Good form design is so amazingly important to usability.. and right now I have so many extra article fields to cover custom cases that exposing the default form scares people. I had to hack it a bit but managed to reduce it to something like this:

Frontend Article Submission Form
 ArticleForm.PNG   48.01KB   59 downloads

I implemented a custom tags field type though in that image - I chose Redis as a backend to store set-type data like tags because it was made to work with this type of information a lot faster than mysql (since the whole redis database is also stored in-memory). It just allows for real-time access to tagged data across any ip.content database.. caching not necessary.

Anyway, there are a million ways I could have formatted that form.. or included extra javascript validation.. whatever. We already know that it takes some skill with HTML to do IP.Content, so form building isn't a major hurdle for people. What may be challenging is just knowing whether or not you have submitted all the fields you wanted.. but you could address that in later versions perhaps by doing some type of ajax form submit where you compare submitted fields against the expected fields and report back to the user. Or be able to put the database into "submission test mode" or something where a submitted record is just validated as to whether everything that is needed to be there is there.. then you give a report back to the user so they know everything is working.

So in short, punt #2 into the future, get form templates in asap, and if you do get around to #2 it shouldn't impact anything in a dramatic way.

[Marcher Technologies]

In reading this, there are a few ways we could go here.

1) We could allow you optionally link a custom template so you can craft the submission form manually. This gives a lot of flexibility, of course, but has the downside of requiring a LOT more work on your part. Then again, it can be optional, so the average user can use the existing submission form, but users with more advanced needs could link a custom submission template.

2) I tend to think this might be a better and more useful approach...we could overhaul fields to support many of these missing functionalities you are looking for.

• Allow fields to only be accepted in specific categories
• Allow fields to show or hide based on values in other fields
• Allow field permissions (i.e. only show a field if you are an admin, or a guest, etc.)
• Perhaps implement custom front-end validators. We have backend validators, but I can see value in allowing front-end validation too (javascript checks before form is submitted)

3) We could look into implementing both, but I'm not sure how much #1 would really be used if fields were fleshed out more and had the capabilities you are really after?


I should note that all of the above are relatively invasive and big changes that aren't likely to make it into 2.3, but I'd like to discuss these ideas further for planning future releases. I think there's some value in the ideas here.

Very Honestly farber.... #1 is all I really need or want... #2 is all fine as well(like the idea) but the fact i would basically have to package up 3 submission templates.... one being a switch and the others the default and mine just to present a customized form in any premade manner is dogs-messy.
I would be thrilled to be able to have a custom form for, example, my media database....
#1 is needed for developers to do much premade forms at all IMHO.

[Darksbane0]

Well I currently manually craft my submission forms when needed anyway so anythign to make this easier will be great. Suggestion 3 of having both would be my choice.

[mat206]

I think when you look over it brandon, #1 and #2 can BOTH be done - what we want is just a way to get going with #1 now. Like, in 2.3 even. Again, it's providing the platform first.. and ironically, none of the people championing this can't hack our ways around alternative solutions. But we know to advance this software the forms need serious loving.. the auto-generated approach is just too messy and doesn't give people the kind of flexibility you get everywhere else with IPC.

In a lot of ways it's a give us this, and let your community surprise you with what we can do type of deal.. because IPC has rapidly become an easy way to generate apps and Marcher has shown with his code that can export databases what we should see on the horizon. I could easily see working with a customer and throwing together quick solutions that I could prepackage for them and have them install onto their board in a virtual folder with pages somewhere. How awesome would that be if we controlled the entire UI experience from submission to display?

[m3rk0rd]

2) I tend to think this might be a better and more useful approach...we could overhaul fields to support many of these missing functionalities you are looking for.

• Allow fields to only be accepted in specific categories
• Allow fields to show or hide based on values in other fields
• Allow field permissions (i.e. only show a field if you are an admin, or a guest, etc.)
• Perhaps implement custom front-end validators. We have backend validators, but I can see value in allowing front-end validation too (javascript checks before form is submitted

I find these suggestions (# 2) more useful to me. The nice thing about this solution is that I get customization without having to write any code. With a few clicks I could have certain fields shown or hidden based on any number of things. I support option # 2 and probably would never need to use option # 1 if # 2 is implemented instead.

[Marcher Technologies]

I find these suggestions (# 2) more useful to me. The nice thing about this solution is that I get customization without having to write any code. With a few clicks I could have certain fields shown or hidden based on any number of things. I support option # 2 and probably would never need to use option # 1 if # 2 is implemented instead.

i come back to this topic with 2 words.
field templates ... for submission and display.
makes form templates somewhat moot.

[mat206]

i come back to this topic with 2 words.
field templates ... for submission and display.
makes form templates somewhat moot.

How does it make form templates moot? Crafting a form is more than just dumping out the field templates. Heck, tell me how field templates is going to reproduce the form I have in the image above.

[aljareh4ever]

did ips change this in the new release or not yet

[bfarber]

No, these changes were not included in 2.3.0.

[aljareh4ever]

coool in my project i heavily modified the skin and how things look like no change for me just few update love it

[MastricX]

Very much would like the ability to customize the submit template.