Re: How do we get there from here?

>
> Maybe. That's not my main aim though. I'm more interested in developing
> tools to automate screen-generation in much the same way as AQL
> generates reports - with a GUI approach rather than a command-line one.
> I know others here have been down this road so I'll have people to
> chat, and maybe share, with on the way.

I've been considering that as well, but not really as a main focus. Our
focus right now is customer service and sales from our commerce portals. I
still think that application web deployment is shakey ground and prefer to
avoid it when I can. If you can grasp XML integration and client development
then you're options are much wider.

>
> Maybe I misunderstood you here? It sure is possible for someone to
> design a page using any WYSIWYG (or WYSIWYkindasortaG) tool with
> embedded tags, or tokens, to be replaced with data. Of course, no page

I'm saying forget about W3 standards and generate your own markup standard
for development. Your standard can be transposed to whatever document format
you want it to end up in. The same "form" layout in MV can be used to
generate XML output as well as HTML output. In order to design using that
proprietary standard, you'd need a WYSIWYG to design the content - or you
could decompile a normal page format into your "markup" standard. Instead of
<TR><TD> you could use ##TABLEROW##. If you are producing an XML document
for something, you could view the context set earlier in the application and
generate a variety of XML representations of ##TABLEROW##.
<PRODUCT><DESCRIPTION></DESCRIPTION><QTY></QTY><PRICE></PRICE></PRODUCT> for
example could be written out in place of ##TABLEROW##, when displaying an
XML product table. You could, though, use SGML as your development markup
and convert it to other formats using standard converters. That would be a
more daunting task, but it would produce an extremely powerful tool unlike
anything out there.

> will render exactly the same in all browsers - and sometimes the data
> will distort the appearance of the page - necessitating some redesign,
> and there are various little issues to be overcome - like with one set
> of radio buttons to return a single value when they're spread over
> multiple (multivalued) rows, etc.. Small things though. Generally, I'm
> more than happy to let a web page designer have free reign to use
> whatever tool they like. I'm coming at it from the angle of plugging in
> the data and managing the way it's used rather than concerning myself
> too much with what it looks like particularly - so long as the
> application doesn't interfere too much with the actual presentation.
> Doing it (providing a tool to be used to design a page) from PickBasic
> is possible too - although I wouldn't waste my time. Visage, for
> example, has a screen-designer that allows you to drag and drop widgets
> onto a form and the parameters of each widget govern its appearance and
> behaviour, to an extent. Drag the edge of a widget out to make it
> wider, or whatever, and it (the Designer application) updates the
> associated parameter. Visage is IE-only, but the Designer's cool.
> Everyone ought to take a look at it at least. Maybe Ross could be
> tempted in to say a word or two about it... ;-) I remember he reacted
> rather oddly once. I was a newbie in the office and was discussing the
> possibility of clients using Visage, with forms designed with FrontPage
> or whatever, over the internet. He seemed to dismiss the idea as
> slightly preposterous. I didn't see why at the time - only when I got
> to know more about Visage. I'm not here to promote it - and I'm not
> here to knock it. I no longer work for them or have anything to do with
> them. I reckon it's worth a look though.

If the web developer can save their WYSIWYG document as SGML, then you
have your solution. There's no need for specialty design applications. SGML
is stable and mature, which is where XML, XHTML, and RSS came from. HTML 2.0
was rewritten as a subset of SGML, but I dunno if it was actually adopted.

>
> One thing I've had some fun with is parsing HTML. Take that variable
> depth table I mentioned before as an example - where the web-designer
> specified what the table should look like and what was in it, but has
> no way of knowing how deep it could be, because that varies with the
> amount of data. It's not too difficult - quite fun actually (if you
> like that sort of thing) - to parse out the <tr></tr>s and the
> <td></td>s with the &nbsps, or whatever, and replace them with 'real'
> rows. My first attempts at this involved stripping out the HTML by hand
> (copy/paste) and storing it separately in segments against the field
> definitions. Hassle. You learn from your mistakes. Better to build more
> intelligence into the application architecture.
>

You would need to do that, if you wanted to decompile a document into
parameters or transpose it into your own markup.

>
> Sorry - but I'm still not clear on this. I've only ever used POST -
> never GET. I guess it's the SSI calls that are outside of this? I
> obviously have something to learn here - which is good. I'm used to the
> idea of controlling *everything* from within PickBasic. This idea of
> having software (PHP? (certainly *not* ASP)) in addition to FC running
> on the web-server, getting in between PickBasic/FC and the browser and
> doing stuff of its own is a little scary. I know the Common Gateway
> Interface takes care of grabbing the images and what not as my forms go
> out the door - that's OK. I can handle anything else that needs to be
> done with assembling the HTML etc. to send and validating/processing it
> when I get something back. What am I missing out on? I looked at
> interfacing with Flash Director early on but that was given the big
> heave ho! - largely due to the reactions of people here. I know Tony G
> must be fuming if he's reading this - after having gone to all the
> trouble of demonstrating how to interact with all sorts of things
> through FC. Maybe one day I'll do something along those lines. All I'm
> really focused on at this stage is browser enabled applications.
>

When Apache gets a request for a file, it will parse the file looking for
SSI tags. This is done BEFORE the document is sent to the browser, outside
of CGI. I have tried to make CGI content be parsed for SSI, but Apache just
doesn't work it that way. SSI allows me, and the designer, to use the same
static HTML file. They design as normal, using a local file include instead
of a virtual call to CGI:

The designer swaps the double-pound to the virtual include when they want
to edit, then back to the "file" tag to hide it from Apache. This works
great in Dreamweaver, especially if you have to edit main content a lot. The
include(s) removes the header and footer clutter from the main document.

<!-- include file="/header.html" -->
<!-- ##include virtual="http://myhost.com/cgi-bin/header.cgi"; -->

Combine that technology with templates that have tokens and you have 2
levels of modularization. You could turn a plain ole` index.html into 3
modular HTML segments:

<!-- include file="/header.html" -->
<!-- ##include virtual="http://myhost.com/cgi-bin/header.cgi"; -->
<!-- include file="/index_body.html" -->
<!-- ##include
virtual="http://myhost.com/cgi-bin/getsection.cgi?index_body.html"; -->
<!-- include file="/footer.html" -->
<!-- ##include virtual="http://myhost.com/cgi-bin/footer.cgi"; -->

POST means two things:
1) This is a submission to the server, not just a simple request.
2) The QUERY_STRING is not the entire request - it's only the <FORM>
"ACTION". The main submission content is transferred after the HTTP header
is sent and is matched by a CONTENT_LENGTH header that tells the server how
many characters to read after the HTTP header has been received.

GET means two things:
1) This is a request from the client, not a large posting of data.
2) There is no "POST data section" to retrieve, only a header. Therefore
the server on has to process the QUERY_STRING header.

URL's are GETs and thus the entire form must be passed as a single
URL-encoded string - no longer than 256 characters. The most deciding factor
on GET versus POST is how much data you plan on sending to the server. If
you have a tiny form that the combined character length will never exceed
256, then it's much better to submit a GET form so you don't waste server
time reading a data buffer after the header. Also, POST data is not logged
in the server logs. If you request a GET from the server, then you can view
the entire request in the logs. This is useful for when you want to extract
"form submission" statistical information from the server logs.

>
> Don't know much about cookies. Never used them. Do they relate to
> individual browser instances - or to the desktop as a whole? I mean -
> if you have two or more instances of IE and/or FF and/or NS running
> different sessions on the same application server, do you have any
> trouble maintaining multiple cookies? I know it's easy when each
> browser page has its own set of variables. Nothing could be simpler. No
> need for any js at all. POST a form and its hidden variables go with
> it. The browser need never know it was there.

Cookies are client/browser specific. They are not browser/instance specific.
Cookies are stored by site domain and URL path for all browser instances. Of
course, IE and FF maintain their own cookie database, so you don't have
cross-over there.
Cookies are very useful for when you want more than one browser instance to
be in the same session, but on different pages. Again, deployment is all
about purpose.
You're building a BUI and I'm building a shopping system. apples / grapes

>
> Yep. That is where I had to step aside from the way FC works. The
> initial form that kicks off the application will be a static page with
> a form with a w3exec hidden value - or as a value in the URL for a GET
> if you like. No state identifying hidden value. FC generates its own
> w3Session hidden variable - but I look for my own, different, hidden
> variable. If it's not there I make it up - and continue to use that
> same name and value in all subsequent POSTS to/from that browser
> instance. It does make a difference how you put your POST together. I
> had all sorts of fun getting this to work late one night - you can read
> about it in a cdp thread (google for ASPick) if you like.
>

That's similar to how my MyAccount session handling works with cookies. I
support a login form and a cookie. If the cookie disappears at any point,
you are shown a login page. The login page puts the cookie back and
continues on. Unfortunately, I'm having compatability problems with cookies.
People have firewalls, spam blockers, and security filters that are killing
things.

>> 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.
>>
>
> Sounds complicated.

It's a rat nest, but it's really kewl! Want a demo? It's not LivePerson or
PageShare, but it does what we need it to do.

>
>> In the end, I'm sure that every page we have will be generated from
>> FC.
>
> Tick. Sorry. That was condescending. It just strikes a down home kinda
> chord. Umm.. I mean it sounds really familiar and I feel comfortable
> with the idea.
>
>> The index page will end up being a mod_rewrite entry in the Apache
>> config.
>
> Why not just a static page with a w3exec value?

I may do that. We still have a lot of design discussions to have before I
get to the technical aspects of anything.

>
>> index.html will not physically exist, instead it will be a FC
>> call to a page generator.
>
> Every page I've produced from FC has been "generated" to an extent. I'm
> not sure what you mean. Why not just kick off the app from a static
> page with a value for w3exec?

index.html will not be a real page. When you request "/index.html" from
Apache, it will rewrite that request into
"/cgi-bin/fccgi.exe?w3exec=getindex" or something similar and process it.
The browser will see content download, but the URL will remain
http://myhost.com/index.html. It's really neat. It's like a "page alias"
sorta..

>
> Yes. I agree that can be a problem. I'd really like it if M$ would play
> by w3.org's rules - but then I'd like to win the lottery too. Where
> w3.org and M$ differ I'll follow w3.org. If IE doesn't behave properly
> then people will probably think it's my fault but I don't care. Truth
> and justice and all that. If M$ offer some features that w3.org hasn't
> agreed on - then I won't be taking advantage of that feature - no
> matter how cool - until w3.org says it's OK. Identifying those
> differences is a pain. Offset to a small degree by repetitive cursing
> at all things M$.
>

Thus my other comments on using JS when it can be used as basic as
possible. Like JS v1.0 stuff. :P

>> >> > 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.
>
> Isn't that just a matter of http: or https: ?

Nope. It's about session state, not the type of connection.

>
>> From there, the header app
>> determines which set of Milonic data files to load(secure or
>> insecure).
>
> Go on then.. I'm lazy. Milonic?

Milonic is a JS based menu system. I maintain 2 sets of data for it. One
set has http links and the other has https links. When someone logins in to
MyAccount the entire header/footer/menu modules switch to "secure" mode and
every link on the website changes to https. This preserves the SSL
connection, regardless of what they click on.

>
>> Afterall, if a session cookie requires SSL and someone
>> breaks out of the SSL chain, then the session will be lost.
>
> How's that? It's no problem to jump in and out of secure mode (change
> from http: to/from https:) and keep hold of a hidden variable. At HHH
> we had an app selling motor and household insurance, prompting for all
> sorts of data requiring a secure connection, before jumping off to a
> secure payment site to validate a transaction before jumping back again
> and finally going back to the unsecured part of the site.
>

If I'm storing a cookie with the "secure" flag set, then the cookie
disappears when the SSL connection does. I have changed that recently, due
to so many SSL/non-SSL browsing problems. A hidden variable would fix the
problem, but I have to redesign the entire web site to handle that. That's
why I'm discussing all of this in the first place. :P


>
> Oh ***. You're gonna hate me here - but I have to ask... Why not keep
> it within D3 and serve it up from there rather than from the web
> server? Size? How long does it take to SCP? How long does it take to
> pipe through FC?

Milonic uses local JS file includes, so I can't just "pipe it". It has to
be stored on the web server as a static file.

>
> Yeah - and we're the ones in the crossfire huh?! I'm just a grunt. I'll
> do my best to stick to the latest w3.org specs. That will help in some
> miniscule way to encourage the vendors to provide w3.org compliant
> browsers - or low and behold - people won't be able to use my site
> properly. ;)
>
> Mike.
>

Unfortunately, most of the web population are not developers who
understand what's what. Most of them use IE.

Glen



--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
.

Quantcast