nloding

I'm pretty sure that the $_SESSION variables are NULL until you run session_start() ... so put the session_start() outside your if/else.

I have an existing site that I want to display a maintenance warning message about across the top. It just a simple div with some text culled from the database. I want the users to have the ability to click the "X" on the side and close it out. Here's the setup for the messages: maint_msgs: | msgid | msg | author | date_added | date_start | date_end | The message is displayed if it falls between the 'date_start' and 'date_end' periods. If the user clicks the "X" ... how do I record that? maint_msgs_user_link: | userid | msgid | I realize this isn't real SQL or PHP, it's just short-handed: $msgid = SELECT msgid FROM maint_msgs WHERE date_start <= NOW() and date_end >= NOW() $test = SELECT * FROM maint_msgs_user_link WHERE msgid = '$msgid' if (num_rows($test) >= 1) { // do not display } else { // display } That seems really tedious to me. But I can't think of another way to do it! Is that the way to go?

Look into regular expressions -- http://www.regular-expressions.info/php.html

Why a rich text editor? That only edits text ... I want the definition to be stored into the database. See my previous post for what keeB was describing -- that's what I'm looking for, almost. I just don't know how to pull it all together into the final form.

In a sense, yes that's what I want. I want the ability to create a custom form and save it's definition. Or to take an existing for and add a field with the click of a button.

I'm looking for any hints or help on storing form definitions into a database. I'm still messing with an issue I first presented in this topic: http://www.phpfreaks.com/forums/index.php/topic,214937.msg981959.html#msg981959 I'm looking at storing the form definition itself into the database -- and I can store it all except the full form. What I mean is, I can store individual items, like a text box, and validators, and actions, and more. But what would the database table/entry look like to define the form itself? Would the database entry be the HTML of the form? That doesn't make sense, because then it's very hard to parse and edit the form. I'm stumped ... and can't find any hints, tutorials, articles, or anything online. I'm actually having a hard time finding any apps that do it, but I know some are out there. Any help is appreciated!!!!!!

Never would have occurred to me. That's a great idea though.

Yeah, but logically, to me, those end up with the same result. Either they are equal or they aren't. 2 * 3 = 6, and 6 = 3 * 2. I was just curious if there was performance difference or something, but it sounds like I'll have to bench it to find out.

OK, so they are of the same type, that makes sense. Is there anything to putting the value or the variable first during comparison?

I'm a little confused. I see this more and more often when I look at open-source apps: if(''===$var) In every article, every book, that I have ever read (not that I've read nearly everything or that everything I've read was good), it's always been this: if($var=='') What's the difference between '===' and '==', and why put the value first instead of the variable? Is there a performance or accuracy difference? Is '===' case-sensitive? How can it be more strict than '=='? I Googled it, but some of the things I read made me more confused ...

I'm confused about why it's bad to just store the data that way. It'd be a long table, but it's not going to be used each visit to the page. And I don't need the form itself in the database -- it's just hard-coded HTML. I'm also considering just generating HTML code and then storing that as TEXT in a database field for the request. My bosses keep adding requirements to this, so my design keeps changing slightly.

But again, that's assuming that the form itself, or the actual form fields, are stored in the database for retrieval. Say I have a form with three textbox inputs ('First_Name', 'Last_Name', and 'Email') and a radio ('Am_I_Dead'). When they fill it out and post it, it would go into my proposed database as follows: | id | reqid (FK) | field_name | value | position | | 0 | 1 | first_name | nathan | 1 | | 1 | 1 | last_name | loding | 2 | | 2 | 1 | email | loding@xxx.com | 3 | | 3 | 1 | am_i_dead | no | 4 | Then: SELECT * FROM request_data WHERE reqid='$req' ORDER BY position ASC And then I can output with simple PHP an HTML table with two columns: Field and Value. PS: I don't care about storing the form itself in the database. I don't care to build my sample "Am I Dead" form by pulling data form the db and building the form. When I said 'dynamic' forms, I more meant that, using Ajax, if a user clicks a certain radio button, various form fields disappear/appear, but it's all posted to one form processing file, and I would like it all saved in the same table.

Ah, that's a great way to store the form, but I was looking to store the data that is entered into the form. The data will then be displayed in just a simple table format when viewing the ticket/request. So I was just looking to store the information posted to the site from the form itself.

That idea detailed above is obviously not suited to this. My next thought was to store XML data in the table as a string, and parse it when it comes out, but there isn't a great way to parse XML as a string instead of a document. And writing that data to a file is just a waste of resources. I've instead decided on having the request table, with a unique request id, and then a request_data table, which has a relationship ID, the request id, the field, and the value and the order to be presented in. Each ticket/field/value combo is a unique relationship, with an infinite number of combo's allowed per request. This also becomes changeable later, if the user wants to modify the request after the fact. Any thoughts on this? This sounds like most reasonable option for what I need to accomplish.

I'm working on a ticketing (support/request) system for my company. We have a standard set of forms that may be used by clients, and I've deemed these "Requests," which are displayed differently as they are populated with form data, not just info from a text area. We want to make these forms as dynamic as we can, so we're looking at dynamically changing the fields depending on what the user chooses (Ajax). Thus, each form posted could contain different fields. Validating this isn't a problem. It's saving the data. What type of design would you suggest? I was going to do a single table for each form type until we decided on making the forms more dynamic and "alive" (as my boss said). So I was then thinking something like this: ------------------------------------------------------------- | id | num_fields | separator | fields | values | ------------------------------------------------------------- | 1 | 2 | <.> | name<.>address | me<.>street Then you can validate the amount of info pulled. I just don't know if the separator idea would work ... what if the request, for some odd reason, contained "<.>" ... I'd need to have multiple potential separators, hence the field. "<.>", "~~!", "&*&" ... whatever. Any suggestions? I want to, theoretically, store any form in the same table, and using (roughly) the same script, pull that data, parse it, and display it in a table, with the fields on the left, the values on the right.