> Yes, I understand the difference between HTTP POST and GET requests.
Good!! :)
> The issue with ND is, what is stopping ND from treating the value
> of a hidden any differently, than say a page session variable? ND
> could _easily_ encode the value of the hidden into the HREF if it
> wanted to. A hidden is constant, unlike say a textbox, or combobox.
I assume that the reason why ND doesn't treat a hidden form field as a page
session object is because they are different things. One's a form field.
The other isn't (necessarily). The former represents a single value. The
latter can be used to pass along a serialized data structure.
Besides, there's some history here. Back in ND 3 days, you couldn't bind a
data field to a page session object, but you could bind a data field to a
hidden field. Most developers didn't want to go to the trouble of adding
code to extract a data field value and pump it into a page session object
when they could just bind the data field to a hidden form field. And,
because the programmers had to add code for HREFs anyway, most decided that
it was just as easy to append an NVP to the URL as it was to store a page
session object. Further, given the length of the URLs created when a number
of page session objects were used and due to the problems created when the
URLs exceeded the IE limit, many people felt that it was better to use NVPs
instead of page session objects. I know quite a few ND developers who even
now think that page session objects are a bogus hack.
On the other hand, other people think that hidden form fields (and page
session objects, for that matter) are a sign of poor design. If you hang
around here long enough, you'll hear lots of different opinions.
Let's face it. For any given programming task, there are probably about a
100 ways to get a working result. Many people live and die by the Studio
and want to eliminate as much custom programming as possible. Others think
the Studio is too limiting and have developed wonderous architectures to
take care of just about everything. Using either approach, or any approach
in between, any decent programmer can get a decent result. Is one solution
any better than the other? It's all going to depend on what you are trying
to accomplish.
In the end, I'm not sure that there's an absolute right or wrong answer.
I'll leave that up to philosophers. I think personal preference rules here.
After all is said and done, we don't have to agree with all of the decisions
that ND has made as long as we know how to work with them or around them, as
the case may be. Personally, I agree with ND's decision not to treat hidden
form fields as page session objects. These are two totally different
things. I don't want things stuffed into page session objects and appended
to HREFs because I've been burned by truncated URLs before.
> I don't like the onBeforeHtmlOutputEvent() approach, because it seems
> too easy for a user to change the value in the URL. Page session
> variables are encoded/encrypted with the other the session values,
> and therefore are much harder to mess with. And in either case the
> URL will get longer, and without testing it, I cannot say which makes
> a shorter URL (generally speaking).
My personal experience has been to avoid using page session objects where
HREFs are concerned. In my early ND days, I was burned several times by
truncated URLs. I became very reluctant to use page session objects unless
there was absolutely no way around it because it's very easy to be
lazy/sloppy and stuff everything into page session objects. If I was
concerned about someone messing with values, I came up with my own
encryption/compression scheme to transfer the data. Other people came up
with the idea of using a single frame frameset so that the URLs never appear
in the location field in the browser. Other people use JavaScript. (See
the archives for more details on these types of things.)
Good luck.
> Nice talking to you.
Hope you still think so! :)
- Grace
_________________________________________________________________________
For help in using, subscribing, and unsubscribing to the discussion
forums, please go to: http://www.netdynamics.com/support/visitdevfor.html
For dire need help, email: [EMAIL PROTECTED]
