Re: How do we get there from here?
- From: "Bill H" <notme@xxxxxxxxx>
- Date: Tue, 1 Nov 2005 21:32:21 -0800
Glen:
There are a __LOT__ of web sites I can't access unless I activate cookies.
I can't tell you how often I try to do something on a web site and finally
figure out I have cookies turned off...then have to open up my browser to
cookies. Once I do that everything works.
Is it possible you're trying too much? I often do this and things work out
a little better when I embrace the limitations. :-)
Bill
"Glen" <nospamwebmaster@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:732bm19l0or8b896vfikn59p2vml8d49ns@xxxxxxxxxx
> >
>>OK. With you there. In my experience this type of "tokenized static
>>template" is something "owned" by a web author - someone who knows how
>>to use a web page design tool to lay out pages of markup, and that's
>>all they need to know. They have sole rights and responsibilities for
>>updating this type of template. They are not interested in what the
>>tokens will become as they will contain no mark-up and will be replaced
>>simply with data. They therefore have total control over the appearance
>>of the data.
>>
>>> or you could dynamically generate your own static pages using
>>> dataBASIC and page format parameters.
>>
>>Do you mean that you can generate pages of markup similar to what a web
>>author might produce, except that it's being generated on a one-off
>>basis from PickBasic? Will it contain tokens that will be replaced by
>>just data at run-time?
>>
>
> Yes.
>
>>> That way you don't have to manually
>>> edit any HTML, just the location of objects, the content, and how it is
>>> styled. I haven't gotten that far yet, mostly because I want a lot more
>>> control over my pages.
>>
>>ED, or maybe notepad, is my own personal favourite web-authoring tool -
>>but that's just me. I did go some small way towards parameterising
>>things that would affect the marked up page but, like you, I can see
>>there is a lot more potential here. All of the properties of everything
>>specified by w3.org could potentially be parameterised. I was working
>>on that.
>>
>
> notepad and vi are my favs. A DOM-based builder is simple in theory,
> but it's a huge undertaking as I'm sure you've discovered. The largest
> benefit would be format options. If you can model all of the document
> formats (HTML,XML,etc) into parameters, no MV developer would need to
> know either of the formats. Of course, using something like that would
> mean building a template decompiler A web designer wouldn't be able
> to design a page solely using cryptic data tags. (eh.. unless someone
> writes a WYSIWYG for the cryptic data tags.. <G>)
>
>>>
>>> > That's OK up to a point. How do you cater for variable depth tables?
>>> > Don't you have to loop generating n lines of markup for each row - and
>>> > then sub the whole of that generated markup into the template? Forgive
>>>
>>> Variable depth tables? I don't follow you. Any token can be replaced
>>> with
>>> anything your mind can dream up. It could be a 100 column, 300 row table
>>> layed out on the fly, a simple IMG tag, or even an entire HTML document.
>>> I
>>> think that's what you were saying above, but I'm not exactly sure.
>>>
>>
>>Well - this is all about separating markup from data. Suppose you're
>>working with a tokenized static template, authored by a specialist web
>>page designer. Somewhere in the page is a table. It will have a fixed
>>number of rows so that it presents nicely in the "mock-up" state
>>without a scroll-bar. If you have imposed some kind of standard
>>token-naming convention for your web-designer to adhere to then she/he
>>would only need to supply tokens for the cells in the first row of the
>>table, and the "page-compilation" process would know it's a multi- or
>>sub-valued field to be repeated for each row. You could then treat it
>>as a fixed-depth table with some form of navigation from one "pane" to
>>the next, or you could extend it to a variable depth according to the
>>amount of data and require the user to use a scroll-bar instead of
>>needing any special navigation. If the latter applies then you're going
>>to have to extract the HTML that applies to a row and repeat it for a
>>variable number of iterations/multivalues/rows. The point is - you're
>>no longer subbing in pure data, it now contains markup as well. This is
>>just an example. I catered for this by allowing segments of HTML (td's
>>and things) to be held as a parameter in a field definition. That
>>meant, though, that there was no longer a clean separation between the
>>template and the data. The web-author no longer had complete
>>"ownership" of the markup. If anything changed - like if the whole page
>>was redesigned with tables dissappearing from one page and maybe
>>turning up in a completely different guise on another - I was faced
>>with having to keep my segments of markup in-sync. It would be nice to
>>have the luxury of being able to control both the page design and my
>>parameters, or markup segments, from the same program/tool - but that
>>would be at the expense of disallowing the freedom and control expected
>>by a bonafide web page designer.
>
> I'm starting on a solution for that exact scenario right now.
>
>>
>>> SSI is an Apache feature where local HTML (or more correctly SHTML)
>>> files
>>> are parsed by the server before sending them to the client. Any server
>>> directives are handled based on the directive type. For example,
>>> <!--include --> tags will insert CGI virtual content(CGI generated stuff
>>> like FC output) or local content into the document where that tag is
>>> located - just like a normal token. ASP has similar features under IIS,
>>> but
>>> I honestly think that what's there is overkill when you only need to
>>> include
>>> content. PHP scripting provides 10 times the features of both of these
>>> options and it will run under most platforms. The main drawback with PHP
>>> is
>>> having to install, configure, and _secure_ your PHP site installation.
>>>
>>> <HTML>
>>> <!-- include
>>> virtual="http://myserver.com/cgi-bin/fccgi.exe?w3exec=get.my.header"; -->
>>> put in some static body content and some ##TAGS##.
>>> <!-- include
>>> virtual="http://myserver.com/cgi-bin/fccgi.exe?w3exec=get.my.footer"; -->
>>> </HTML>
>>>
>>
>>I don't understand why you'd want to do this. Why not bring things in
>>from the cold (web-server) into the warmth (PickBasic)? I know you were
>>doing things with FlashCONNECT for a long time. I'm curious - why'd you
>>abandon it?
>>
>
> 98% of our web site is generated through FC. The rest is either HTML
> of JS. Unfortunately, FC is too limiting when you want to do things
> outside of a typical HTTP POST/GET. Too much massaging is required and
> I've since tried to write my own interfaces and/or integrated external
> tools. That's where D3WWW and finally MVWWW came from.
>
>>> > post initiated by a submit? The header and footer templates I'm
>>> > familiar with (as would be anyone who has used FlashCONNECT) - but I'm
>>> > not clear on how they "completely change states based on the browser
>>> > session". Is it that you use them for a collection of hidden fields?
>>>
>>> Most of the static pages we have is what you see above. It's a mixture
>>> of
>>> SSI calls, tags, and a little static HTML code. The header and footer
>>> are
>>> both tokenized, so the content in them is session driven by cookies,
>>> state
>>> files, and URL post/get parameters. The shopping cart tag/ling and
>>> "myaccount login/logout" link are both session driven.
>>>
>>
>>If you're serving everything up from inside PickBasic then you don't
>>need anything beyond a single hidden variable to maintain state - not
>>even cookies, which could be turned off. This can be really simple.
>>Just write your working storage out to a file keyed on the value in the
>>hidden variable (or an encrytption of it if you like) before you post
>>and read it back in when you get the post back. Voila! Your working
>>storage / state variables are all restored.
>>
>
> It sounds that simple, but it's not. If you don't have a solid way to
> pass a session key from request to request, then the local server
> state information will be soft and volalile. If you have just a single
> static page that does not return back to the dynamic environment, then
> it's the same situation as a recursive subroutine call that stops with
> an END statement in the middle somewhere. Cookies are the only
> persistent method of storing session keys without having to perform JS
> form voo-doo on every single page. Keep in mind that the document and
> existing key must be generated from the original execution, in order
> to maintain the chain. Just using a static page with an SSI call to
> the dynamic environment won't do the trick. The SSI call will not have
> an existing key to pass inward, since the technology is based on a
> stationary file. So, how do you get around it? I'm still trying to
> figure out a good/efficient solution, without having to store crap in
> a hidden frame. I ended up having to do that in my co-browsing
> application, after encountering way too many DOM differences between
> browsers. It's not a pretty thing, but it works well.
>
> In the end, I'm sure that every page we have will be generated from
> FC. The index page will end up being a mod_rewrite entry in the Apache
> config. index.html will not physically exist, instead it will be a FC
> call to a page generator. That is going to take some time and that's
> the reason I haven't done it already. We're working to get there
> though.
>
>>I did use tokens in the header and footer, but they were for things
>>like page navigation, error message displays, general look and feel,
>>etc.. Which was, or could be, dynamic.
>>
>>> So, what's so special about all that? Nothing really. You can do it
>>> with
>>> Perl, PHP, and just about any other scripting language. The beauty of
>>> how
>>> it's implemented is the fact that apart from a couple of token subs in
>>> MV, I
>>> didn't have to program anything special. There is some javascript for
>>> certain functions of checkout and the main menu is JS, but in general
>>> the
>>> web site is JS free, scripting free, yet it is still completely session
>>> driven.
>>>
>>
>>I don't see it as a goal to be js-free. On the contrary I see js as a
>>boon. Why are you anti-js? What advantages, other than being js free,
>>are you seeing?
>>
>
> JS is not MS JScript, which is one of the biggest problems. The DOM
> access methods are totally different between MS and the rest of the JS
> 1.1-1.2 world. Some methods that are "standard" have yet to be
> correctly implemented by MS. Some of them have been implemented in an
> incomplete way (read-only for example instead of read/write) or not at
> all. I choose to eliminate JS due to the fact that I can't write a
> viable solution unless I spend way too much time tweaking 3 times the
> amount of JS than I should have to! It's much easier to work around it
> with rock-solid methods and use basic JS in the simpliest means.
>
>>> > Sorry if that's way off the mark. The JS product menus - is it that
>>> > you're generating javascript? This sounds interesting - if you need a
>>> > menu to navigate products, is it along bill-of-materials lines?
>>>
>>> Yes, well not at each browser hit. The product and vendor menus are
>>> generated by our software on a nightly basis or if someone runs the
>>> update
>>> tool.
>>
>>Couldn't they be generated/compiled on a jit / as required basis? I
>>mean, as they are posted to the client/browser?
>>
>
> The site header contains a session token that determines if the user
> is logged into a secure account or not. From there, the header app
> determines which set of Milonic data files to load(secure or
> insecure). Afterall, if a session cookie requires SSL and someone
> breaks out of the SSL chain, then the session will be lost. The rest
> is up to the browser to load the JS stuff. There so much data there,
> it's not efficient to dump it at each request. That's another issue
> we'll be addressing in the redesign.
>
>>> The JS data is generated from a product+category tree and then
>>> automatically SCP'd
>>
>>SCP?
>>
>
> Secure copy. It's like the SFTP subserver of SSH, but a faster and a
> more accepted method of copying files over SSH. Most Linux boxes have
> SCP and SFTP installed with the SSH server.
>
>>> over to our webserver. Is that special? No, not if
>>> you're used to using MySQL and PHP to build dynamic menus everytime
>>> someone
>>> clicks a link.
>>
>>There's no difficulty at all in generating dynamic menus from
>>PickBasic. It's been common for CUI for ever. No difference really. I
>>need to understand why you're not doing this anymore.
>>
>
> It's easy, but it's quite intensive on the services if you have
> hundreds of menus and submenus in one tree. I'd rather let FC perform
> the more important duties and leave the menu building to local
> end-of-day scripts. Afterall, we don't change them that often.
>
>>> This is just a good example of how something as simple an
>>> idea as tokens can eliminate a huge amount of maintance, increase server
>>> performance, and still achieve dynamic presentation.
>>>
>>
>>Well - "eliminate" completely would be nice.
>>
>
> We're getting there.
>
>>> >
>>> > The OP, what I was attempting, was to see who had gone down which
>>> > roads
>>> > and what they'd encountered along the way (good or bad things). I'm
>>> > particularly interested to hear back from one chap who mentioned he
>>> > was
>>> > doing things with xForms a while back. Also - I've seen the way some
>>> > people are doing things and, in some cases, they seem to have, if not
>>> > burnt, then severely weakened the bridges between the starting post
>>> > (pure Pick - options all open) and where they have taken their
>>> > development efforts to date.
>>> >
>>> > Mike.
>>> >
>>>
>>>
>>> I have gone down a lot of roads in my 10+ years of web development.
>>> Each
>>> one had good points and bad points, but those are _always_ relative to
>>> the
>>> project in focus. You can't judge the road handling capabilities of a
>>> vehicle if you run it in stop-n-go traffic. If you have a specific
>>> example
>>> of an idea you want to bring to fruition, then it would be much easier
>>> to
>>> make suggestions on which technologies should be reviewed for their
>>> pros/cons. Saying that xForms/PHP/MV.NET/etc works the best of all
>>> technologies to make MV web savvy is totally ignorant and you really
>>> should
>>> ignore the person preaching about the technology that just happens to be
>>> in
>>> the spotlight at the moment. :P
>>>
>>> Glen
>>>
>>
>>But that's just it - I *am* looking for the "best for all" way to go.
>>The point is that I'm coming at it from Pick. I therefore want to
>>maximise Pick's capabilities. Absolutely. What's special about Pick?
>>How does it differ from other database and/or application servers?
>>Where can I maximise my leverage? Number one - keep the driving
>>application code inside the Pick DBMS. Number two - maximise the power
>>of the browser / presentation layer. Each to its strengths. One thing I
>>haven't figured out yet - personally - is what to do with the
>>web-server in the middle (other than to simply keep things passing back
>>and forth quickly, smoothly and securely, and to store my binary
>>files).
>>
>
> I agree that the central control of business rules and application
> code is one of the best aspects of MV. However; that doesn't mean that
> you have to develop your web site completely in dataBASIC. You can use
> existing business rules, FC, dataBASIC, your own dynamic XML, and
> Flash to create a powerful web interface. I'm going to be playing with
> that very shortly for a project. For now, I'll be testing the XML with
> PHP command line stuff.
>
>>Personally, I've favoured the road marked by w3.org. Whatever I learn
>>from this thread I'll be keeping that road open - no matter what. I'll
>>preach Pick and I'll preach w3.org - without the slightest qualm. I'd
>>be very hard pressed to preach in favour of M$ though - even if that
>>appears to be the road most travelled.
>>
>>Mike.
>
>
> Unfortunately, you are going to have to contend with Microsoft and
> their fearless attempt to control the Internet, er I mean browser
> market. When you talk about customers shopping your sales site, you
> can't assume that most of them will be using FireFox and therefore you
> can adhere and develop around the W3 standards. 98% of them will be
> using the most recent version of I.E. which could care less about
> meeting W3 standards as they are published. The other 2% can't be
> ignored either. It's a tough world.
>
> Glen
>
> --
> Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
> ------->>>>>>http://www.NewsDemon.com<<<<<<------
> Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
.
- Follow-Ups:
- Re: How do we get there from here?
- From: Glen B
- Re: How do we get there from here?
- Prev by Date: Re: Need help using Progress OpenEdge to connect pull data from a unidata db
- Next by Date: Re: How do we get there from here?
- Previous by thread: Need help using Progress OpenEdge to connect pull data from a unidata db
- Next by thread: Re: How do we get there from here?
- Index(es):
Relevant Pages
|
