I was thinking of something similar, but instead of using the form block, and form results, it would be a "page creator" taking advantage of the existing concrete page features (permissions, versions, etc). You could select which questions where presented to the user from already existing page attributes (created in the dashboard), and after the user fills out the form, it just makes a new page of a certain page type (block options would let you specify the created page type). So in the case of real-estate listings, you'd make a "listings" page type. (now I'm wishing that the contests add-on was made in this way).

yeah the way i imagined this working is adding another option to the editing toolbar in the content editor of merge type fields. this could be all of the common user object stuff for logged in people, some standard stuff like date/time, maybe custom fields for the page, and perhaps you could point it to any form that was in the system as well and get the form fields?

then the form block would have a target page selector like the search block does and on submission it would goto that page and yer merge fields would give you the nice "Hello _Tony_," experience everyone is talking about..

I think this would be an awesome feature. The way Tony described it would be awesome as well but I would make that a separate feature. This would be perfect for many things like the real estate listing example you used or things like a classified website.

I vote "hells yeah"

I would love to see a simple real estate package like jgarcia mentioned. This would lend to what Tony and Frz said as well since you would be able to use this sort of package for various things.

If it used solely as a Real Estate package, how then would you integrate MLS data? Not sure if this would be applicable but since I have recently sold a house, the realitor's use a posting system that integrates with their local MLS. As an independent realitor not too worried about the MLS, I think this would be a great thing.

Again I could see this being used for various things. As an example of another type of use, I am restoring a 1968 F100. With some data text changes and a little tweaking of the page wordings, this could be used as a community postings package for restoration.

So yea, something of this nature would be great.

I'm not sure what the extent of MLS integration you are referring to is, but I would think to keep it more generalized, rather than customizing it to only fit a specific purpose. That way it could be used for a wide variety of purposes. Though depending on how exactly the integration would work, it might could be something that could be coded into a custom view template for the block.

I'm still kinda thinking through this, and I probably won't be able to really focus on it until September, but I'd like to start piecing ideas together, so if anyone else has thoughts, feel free to contribute.

I did something like that actually for my first c5 site. We accomplished that by embedding an old propietry CMS we had into c5.
Have a look for example at this link for the front end:
http://www.goodhealth.co.nz/products/-/browse/ailment_specific...
Have a look at the attached screenshots of a backend (from another site)
You setup the tables in a config file and then access them trough the dashboard. I've been planning to package it somehow, clean up the code and release it, just never got the time.
Also I'm still not sure whether this package should create actual pages or not (at the moment it doesn't).
Pros of creating pages:
- You get SEO friendly URLs out of the box.
- You get front end c5 search integration out of the box
- You get access to all existing and future blocks to build the content. EG: the Real Estate database would use the Google Maps block.
Cons:
- You loose control of what content people use (unless you use advanced permissions)
- You are basically trying to re-write the way c5 manages pages.
- You need to somehow make sure that the sitemap is in sync with whatever interface you choose to implement. I mean, what happens when users go to the sitemap and manually edit your pages?

As a side note I get the feeling that people are constantly trying to reinvent the way c5 manages pages (I admit being one of those people). The way c5 does it is perfect for us web developers. It gives us a lot of flexibility and creativity and it's probably the main reason all of us were blown out and stuck to c5 in the first place. But somehow the whole blocks concept doesn't seem to work for our end customers who (we think) would much rather have the "all options in one screen" from other traditional CMS systems. A perfect example is the whole Blog discussion. We all know how to add a couple of content blocks, a guest book, maybe the "add this" block, a custom page list, etc. But we wanted end customers to be able to manage the whole thing from one single screen and with a few clicks. As a result we'll be seeing in the marketplace two excellent Blog packages which will fit that target audience. But at the end of the day, it's just a way of reinventing the way pages are created.

I actually started building something similar to that.

I use "real pages" to store my data. I simply create attributes for each column to store the data. This way the user can edit the page without my "interface" and everything is still in sync.

it doesn't have such a nice interface tho.

If you still want to finish that thing, we can team up if you like..

...at least in regards to what I had in mind. The form block is one of the most complicated blocks we have (largely due to things like question versioning), and the data-structure is not very easy to work with. It anyone want's to try this kind of thing with that approach, be my guest, but the created pages won't have the advantage of all the built in concrete functionality (search, user permissions, editable, versions, etc).

That's almost exactly what I was thinking.

Couple of questions:

1 - were the forms actually created using the Form block in a way, or is this just a custom form you made?

2 - You say the tables a setup in a config file. is this the table where the database info is stored (such as the attributes of the wine product in your images), or is that info stored in the typical Form block table

I honestly like the idea of it not creating individual pages. I field like you can do more with just a basic form that you can with page attributes, and make it easier for a non-tech user to manage...though I have to admit that I am not incredibly familiar with using page attributes, and may not be aware of the capabilities. But I feel like some thing might not be as doable with page attributes - for instance, a file upload field. Don't think you could do this with page attributes...someone tell me if I am wrong about that.

I really like what you've done to matogertel - nearly exactly what I had in mind. My main question, as I mentioned - is where/how did you setup that exact form?

you can create a file/image page attribute!

I'm using this attribute to add pictures to my navigation.

You can easily use it to save files in different ways..

The tables are actual database tables, although my model supports dynamic tables as well. What I meant by the config file is that rather than having a fancy GUI for defining the forms, I have a PHP file with some lines of code that define how the database fields map to form fields. Symilar to how Symphony does it with YML. So the form is created dynamically from that config file. I don't need a fancy GUI for it like the form builder cause the package is intended to myself rather than end users.
Remo, regarding creating actual pages with page attributes. I thought about it, but I always go round in circles. My main concern is, if c5 already has all this functionality, why are we trying to reinvent it? Should c5 offer an alternative page creation process for non power users out of the box?

Being able to create pages within a table might be very nice if you want to manage products for a shop. Set some attributes (color, size etc.) on the table where you have a nice overview and if you need to add some details like a video go and edit the page..

It wouldn't reinvent the functionality but rather use the existing functionality. It would only be another interface where you have a better overview in some situations..

using page attributes has another advantage.

Table definition - there we woudln't have to reinvent anything. Concrete5 allows us to create page types (~= table) and attributes (~= columns).. That makes a nice table definition gui

Here's (i think) a key advantage of using form data rather than real pages - it allows you to let people add data (or another "page") without actually being an administrator on your site.

granted there are instances when you wouldn't want this at all (if the data only needs to be managed by an administrator), but let's say you're getting some sort of user responses - similar to a guestbook, but with maybe some more customized data. is there (again, i may be unaware if there is, as i was about the "file" page attrib.) a way to allow a non-registered/non-admin user to add a page. i'm sure there probably is a way - everything's possible. but for some reason i feel like there are more possibilities with simply stored the data as form data rather than an actual page - i feel like there might be more flexbility, which i think would be key.

matogertel - you don't have a live demo of what you've done anywhere that could be viewed from the admin side? your screenshots were very close to what i had in mind, but it would be cool to check out the actual functioning of the admin side. if not, no big deal.

Well, advantages of using my own data type so far are:
- I have many more custom field types than the ones built into c5 (I already talked to Franz about allowing third party custom field types).
- I control exactly what and how information is displayed.
- For some applications, creating a whole page for each entry would be an overkill. EG: testimonials, guestbook.
So I guess there's a market for a package based on custom data types.

In regards to: "Here's (i think) a key advantage of using form data rather than real pages - it allows you to let people add data (or another "page") without actually being an administrator on your site."

I don't see why you'd need the form data approach in order to do this. You could still use a block with a similar interface, and you could have it create pages. The view mode of this block would just be a public facing html form, asking users for the required info (the required info would depend on what Page Attribute checkboxes were checked while editing the block). Those pages could either be instantly public (maybe a captcha would be required in this case), or the block could set them as private (no guest viewing privledges), and it could set some other page attribute flag like "Pending Review".

I agree about the overkill. Creating a page for a simple list with a single attribute but 100'000 entries might be too much..

But I still think that block would be really handy. I already have two projects where I could use it..

As a simple database table builder it would be very easy and powerful to use.. Whether it is about managing real estate info or products within a shop.


You can be sure that if no one starts working on that within the next 2 months, I'll take that challenge. I already have some code and I coudl use it. There are just too many consulting projects going on at the moment.. And I have to write a thesis as well.

that just tabular form data is the way to go, as opposed to actual pages.

there may be situations where actual pages will be useful, so maybe another block/package would be suitable for that.

i'd like to try to take it on, but wouldn't be able to until september...like Remo, I'm pretty busy until then.

Has anybody released some code about any of these approaches we talked about?

I might have to build/extend something sooner than I thought and would love to be able to check some other approaches/ideas first..

This is a tricky thing. Many of my clients and 2 of my partners are Real Estate agents and I have had to tackle these issues in the past. The trikky part is that different regions use different MLS systems, and almost none of them work the same way. Take rapitonii for example. They are very tight with security for obvious reason but it makes integrating difficult. I have used realtysoft.com's free IDX tools to embed in my c5 sites but that is not really a very good solution. Maybe some kind of screen scraper or a feed directly from Realtor.com(the organisation that holds a monopoly on real estate), would be best.

Anybody that is able to solve this problem of flexible MLS integration would have my business for sure.

One thing to keep in mind though if MLS integration is not possible. Agents hate entering data and most MLS systems require a tremendous amount of data. So if the c5 system was not able to pull this data from an MLS, the input form that ads a listing to a c5 site would need to be very small. Having to duplicate all the work can be very tedious and time consuming and agents need to be out in the field, not stuck in an office.

As I said before, the package I currently have is basically a propietry CMS we had that we embedded into c5. So currently the status of this package is the following:
- I need to get approval from the company I developed the package for to put it on the marketplace, they are currently thinking about it.
- There's a chance the released package will be a lite version of what we currently have
- It will be a data builder, not a page builder (at least in it's initial release). From the discussion above I see there's room for both.
- May take a while before it's actually released :-(

Hey Matias,

I started building my own table manager (not use page attributes).

I'd like to use the sql table definition and nothing else like a meta/xml file.
This however seems to be a bit strange since I need some more types which don't exist in sql.

I could use something like varchar(255) for text and varchar(254) for a file/picture, but I'm not really convinced by that..

Any ideas? How did you do it?

Remo

Hi Remo,
If you want to store the files in the database (which I wouldn't recommend) you need to use the Blob column type. If you want to store the path to where the file is located then a varchar 255 (why 254?) is fine. That's what I do in my current library. Another approach is to use c5's file manager and just store the fID.
I decided I'll take what I have as a example and try and do a light version from scratch using only c5 libraries (well, maybe with just a few additions). I got caught up with some real work from customers which I need to finish, and still need to post the video for the area splitter and the tag cloud... So not sure when I'll be able to do that. I was hoping to release it as a paid package aswell.

hey guys,
i had a slightly different approach using this than using an XML file to determine the field type. i am basically just using the form block to store my data. i've gotten a small start to it and here's what i've done so far:

I created a new page in the dashboard called "Form Templates" (name will probably change) with two other subpages (will get to those in a minute). basically the main page allows you to add only "Form" block types to that page, so that is essentially where you are setting up the "database". the page lists the forms on it and lets you add the data directly there (you click on the form name and it expands down with the form you can add data to). should you want to make any of these forms public, they can be copied to the scrapbook and adding to pages from there. a screenshot of this page is attaching (though the page is not fully complete).

there other two pages are a "List Templates" page and a "Detail Templates" page. Those are somewhat self explanatory. "List Template" are used for listing out the data (the template repeats for each form submission you have) and the "Detail Templates" are for displaying detail on a single submission.

the final portion of this application would be the actually Data Display block. you would add this block to a page - select the form name, list template, and detail template (along with a few other others i'm in the process of determining) and then the block displays that data on the page.

my thought is to utilize what already exists in c5 rather than build something up from scratch. the Form block already has in place the process of determining the data type, rendering the form, and storing the data. I'm just building off of that.

See the attached screenshot and let me know your thoughts.

I like your approach. Really straight forward. (To be honest, I didn't think you could add blocks to the dashboard, but hey, why not?! great!)
I still don't get the templates areas. I would have thought you define the templates in your blocks. Like have a form list block and a form details block, so you use custom templates in those blocks.

but in my case it's has a big advantages to use "real tables".

I'm porting a few things to Concrete5 and it's a lot easier for me if I can simply copy a table from old system to the new one.

Your approach does make sense of course, but it's about different needs. I guess we could use 5 different packages about data management (:

I don't want to save files in the database, at least not for 98% of all my projects.

But I still need to know where I have to show the file selection dialog.

I could check for fID but what if someone else wants to have a second file column? I could probably check for "f" at the beginning of the column name.. What about page selection? "p%"?

In my first approach I would have used the length of varchar to distinguish between a "short text field" and a "file field"

I already started building my table manager.. It does quite a few things so far but it doesn't edit any kind of data yet.

I intended to release it for free actually.. Guess I'd be a nasty competition /-:

Ok, now I understand your question Remo, I think!
You want to autodetect the column type from the table definition. In my case, I have the mapping defined in a configuration file, so you can call columns however you want. Also, you can store any type of data in any column you want and also give them nice names, but it requires you to manually map the columns to some kind of structure in a configuration file.
Regarding paid vs free, I'm torn between free and paid releases. On the one hand I see other CMS systems where pretty much everything is free. On the other hand I like C5's approach where you pay between $5 and $15 to the developer just as a token of appreciation. Most of the time the end customer will pay that money anyway and then all of us win. Also, not all the ideas I think of are useful to my customers, but I know they will be to other people in this community, so I spend my own time writing the code and it's nice to get a few bucks back.
But still, everybody likes free stuff :) I do!

I want to avoid any unnecessary files.. Otherwise I would have to create a mapping gui as well (:

About paid stuff. I need money like most other people on earth.. But I still like the "open-source spirit" (which doesn't mean free by definition). But free and open is nice.

I have to admit though, it's getting harder and harder to publish stuff for free since more and more people are earning money with what they do on concrete5.org

I also like free addons because they allow me to learn something about a system very quickly. If you understand the basics, it's very easy to into the more complicated stuff.

We'll see - for now I intend to be nice and release stuff for free (: I would probably add a donate button though ;-)

i used to think i was kind of being a jerk by wanting to make a little cash off of stuff i made. then someone brought to my attention the fact that *most* of the time, developers are purchasing these things for sites they are doing for a client, in which case they can just pass the cost on to the client. in cases like that $5, $10, or even $50 is minimal.

of course, i definitely don't mind when people put free blocks up (i love the image zoom block remo - just implemented it on a site, very nice and easy!), and i hope to do a few myself in the not so distant future. but i do now not feel guilty for having paid blocks up on the marketplace either.

I agree with you both. Not much more to add there...

Remo, the GUI for the mapping is what jgarcia did with the form block. If I was to finish my data manager someday I would definitely put some kind of gui like that because the audience is not just developers but general people using c5.
I like the idea of auto-generating the definition out of column types (or column names) but that wouldn't appeal to non-experts either.
As a personal choice I like configuration files cause it means when going from dev to live you don't have to recreate all those definitions in the live db. But again, only a smaller audience would like that.