------------------------------------------------ On Tue, 22 Jul 2003 09:33:28 -0500, Peter Fleck <[EMAIL PROTECTED]> wrote:
> Thanks to all for the help on 'clearing the form' and for forcing me > to face the design limitations. > As long as you realize them then that is most of the battle, all of us have to face hacking around them because outside factors (like budget and schedule) have caused the need. > I would prefer to preview the data before storing in the DB and had > hoped to get this in place but ran into a problem on the way which > led to my workaround which and the STORE-PREVIEW-DELETE ENTRY-EDIT > sequence. I don't like it either. > > The problem is that I am storing a series of entries to a table in a > hash with values that reference arrays. I don't think I can store > something like that in a hidden form field so I have to > rethink/redesign that whole data storage process. Would it be safe to > say that only scalar values can really be hidden away in fields on a > form? (I also have some values in an array that would have to be > taken care of.) > Well storing complex data structures is possible, you just have to serialize them first, then on the other end reload them. Granted this can get ugly depending on how complex the structure is, especially since you have to store it into HTML which means you need to account for special characters, etc.. There are numerous CPAN modules that provide this type of functionality if doing conversions on your own isn't possible. Because a hidden field can really contain any amount of data (though I wouldn't use a GET) you should be able to serialize the data into a single string and store it in a hidden field. > I'm starting to conceive as to how it can be done but I'm also way > behind schedule on this project. So the 'good' design will have to be > implemented in the next rev of my ap. > Understood. > Just to provide a bit more entertainment for you experienced perlers, > my intermim/ugly hack solution to the back button problem is to add a > field in the DB that must be true for the data to display on a Web > page. The default value is 'false'. After previewing the data, the > user clicks an button which simply sets the display column value to > true. So if user uses back button, an extra record will exist in the > database but that record will not show up in public display. > Actually I like this, the only thing I would add would be a revision identifier. Make it a two step process, aka a new revision must be added then it must be "committed" or the like, not unlike a version control system, I am working on implementing this on all components of my new site. Then you end up selecting the most recent (greatest) revision that is active for display, but can always roll back to a previous revision, simply by deactivating the most recent addition. Of course there are other issues with this technique, aka storage space, do you store the complete entry or just a diff, locking, etc. > Background: This is a data entry system for one person/editor that > will then result in dynamic display of information for the public on > our Web site. Right now the person is maintaining the page in HTML > Netscape Composer so it's hard for anything scripted not to be an > improvement. You can check the current site at: > > http://www.cancer.umn.edu/page/aboutus/grantopp.html > Sounds like it is definitely an improvement. I would say the issues you have encountered are fairly regular and can't really be taught around, in most cases the only way to avoid them is to have already experienced them (and trust me I have). http://danconia.org -- snip old messages -- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
