[Proto-Scripty] Re: How to handle non-JavaScript browsers when using Ajax.Updaters for content
My opinions on this are, if each page is going to be ajax'ed in, then
why not just have them on a separate page right now anyway? You've
obviously found a couple of huge problems with AJAX'ing content and
I'd add a major third: history. It screws with the back buttons,
especially if you don't sort the problem where each "page" doesn't
have a url from which your system can generate that "page" from
scratch.
My approach is to only use AJAX where it's hiding/showing a specific
part of a page, or updating specific elements on the page. For
instance, on the site I'm making right now, a user has a number of
fields split into tabbed fieldsets - I've got JS hiding/showing the
fieldsets as each tab is clicked. For me that's fine because no-one is
ever really going to want a link straight to a specific fieldset,
they're all part of the same page, and it's obvious it's happening
live because only sections of the page change rather than the whole of
the main content.
That's my "two cents" as they'd say in America thrown in. Apologies
for not involving myself in the technical aspects of the discussion!
On Sep 12, 8:16 am, "Dustin S" <[EMAIL PROTECTED]> wrote:
> True. We actually dabble in Catalyst w/ Template Toolkit, but so far have
> actually found it far more intrusive that helpful to our online application,
> hence we're hand coding everything on the production site to-date [using
> handmade HTML, PHP, Prototype, LivePipe, and a dash of Scriptaculous!).
>
> I also completely agree that the use of Ajax is to optimize in
> new-and-awesome ways for the user experience, which strictly speaking has
> the exact effect you mention: extra work coding to make those optimizations
> happen.
>
> With that said I refuse to make things ugly server side because we want to
> optimize past web 1.0 using an Ajax framework yet maintain backwards
> compatibility. I'm going to push on with this problem and hopefully come up
> with an elegant solution to the hybrid goal of Ajax-y goodness and SEO
> (which is the real reason anybody should care about non-JavaScript support
> IMHO).
>
> I'll of course post back with anything we can come up with...
>
> cheers-
>
> On Thu, Sep 11, 2008 at 7:48 PM, Ken Snyder <[EMAIL PROTECTED]> wrote:
> > On Thu, Sep 11, 2008 at 6:19 PM, dustin <[EMAIL PROTECTED]> wrote:
>
> >> That seems like it would work nicely, but doesn't it pretty much
> >> negate the gracefulness of using Ajax to insert content into a DIV
> >> (the grace that allowed me to stop maintaining clumsy header.php,
> >> footer.php, navbar.php, etc, and piecing together based on the user-
> >> agent type)?
>
> > Yes, I was oversimplifying. If you use an MVC system, you shouldn't ever
> > have to worry about headers, footers or nav bars.
>
> > With MVC, the layout template echoes your content. When requested by ajax,
> > the layout template will be blank. Otherwise the layout template will be a
> > complete page minus the content. For example:
>
> > empty.phtml:
> > -
> >
>
> > htmlHeadAndFootAndNav.phtml:
> > -
> >
> > ...
> >
> >
> >
> > ...
> >
> >
> >
> >
> >
> >
> >
>
> > myContent.phtml:
> > -
> >
>
> > Content...
>
> > > $content = ob_get_clean();
> > if ($_REQUEST['ajax']) {
> > include 'empty.phtml';
> > } else {
> > include 'htmlHeadAndFootAndNav.phtml';
> > }
> > ?>
>
> > Ajax isn't traditionally used to make less work on the server side; it is
> > usually implemented to reduce page load times and allow immediate feedback
> > for simple actions. If you're looking for better content management, start
> > with a CMS or an MVC framework on the server side.
>
> > Oops, that was a long answer. :P
>
> > - Ken
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: How to handle non-JavaScript browsers when using Ajax.Updaters for content
True. We actually dabble in Catalyst w/ Template Toolkit, but so far have
actually found it far more intrusive that helpful to our online application,
hence we're hand coding everything on the production site to-date [using
handmade HTML, PHP, Prototype, LivePipe, and a dash of Scriptaculous!).
I also completely agree that the use of Ajax is to optimize in
new-and-awesome ways for the user experience, which strictly speaking has
the exact effect you mention: extra work coding to make those optimizations
happen.
With that said I refuse to make things ugly server side because we want to
optimize past web 1.0 using an Ajax framework yet maintain backwards
compatibility. I'm going to push on with this problem and hopefully come up
with an elegant solution to the hybrid goal of Ajax-y goodness and SEO
(which is the real reason anybody should care about non-JavaScript support
IMHO).
I'll of course post back with anything we can come up with...
cheers-
On Thu, Sep 11, 2008 at 7:48 PM, Ken Snyder <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 11, 2008 at 6:19 PM, dustin <[EMAIL PROTECTED]> wrote:
>
>>
>> That seems like it would work nicely, but doesn't it pretty much
>> negate the gracefulness of using Ajax to insert content into a DIV
>> (the grace that allowed me to stop maintaining clumsy header.php,
>> footer.php, navbar.php, etc, and piecing together based on the user-
>> agent type)?
>>
>
> Yes, I was oversimplifying. If you use an MVC system, you shouldn't ever
> have to worry about headers, footers or nav bars.
>
> With MVC, the layout template echoes your content. When requested by ajax,
> the layout template will be blank. Otherwise the layout template will be a
> complete page minus the content. For example:
>
>
> empty.phtml:
> -
>
>
>
> htmlHeadAndFootAndNav.phtml:
> -
>
> ...
>
>
>
> ...
>
>
>
>
>
>
>
>
>
> myContent.phtml:
> -
>
>
> Content...
>
> $content = ob_get_clean();
> if ($_REQUEST['ajax']) {
> include 'empty.phtml';
> } else {
> include 'htmlHeadAndFootAndNav.phtml';
> }
> ?>
>
>
> Ajax isn't traditionally used to make less work on the server side; it is
> usually implemented to reduce page load times and allow immediate feedback
> for simple actions. If you're looking for better content management, start
> with a CMS or an MVC framework on the server side.
>
> Oops, that was a long answer. :P
>
>
> - Ken
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: How to handle non-JavaScript browsers when using Ajax.Updaters for content
On Thu, Sep 11, 2008 at 6:19 PM, dustin <[EMAIL PROTECTED]> wrote: > > That seems like it would work nicely, but doesn't it pretty much > negate the gracefulness of using Ajax to insert content into a DIV > (the grace that allowed me to stop maintaining clumsy header.php, > footer.php, navbar.php, etc, and piecing together based on the user- > agent type)? > Yes, I was oversimplifying. If you use an MVC system, you shouldn't ever have to worry about headers, footers or nav bars. With MVC, the layout template echoes your content. When requested by ajax, the layout template will be blank. Otherwise the layout template will be a complete page minus the content. For example: empty.phtml: - htmlHeadAndFootAndNav.phtml: - ... ... myContent.phtml: - Content... Ajax isn't traditionally used to make less work on the server side; it is usually implemented to reduce page load times and allow immediate feedback for simple actions. If you're looking for better content management, start with a CMS or an MVC framework on the server side. Oops, that was a long answer. :P - Ken --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: How to handle non-JavaScript browsers when using Ajax.Updaters for content
That seems like it would work nicely, but doesn't it pretty much
negate the gracefulness of using Ajax to insert content into a DIV
(the grace that allowed me to stop maintaining clumsy header.php,
footer.php, navbar.php, etc, and piecing together based on the user-
agent type)?
On Sep 11, 3:41 pm, Ken Snyder <[EMAIL PROTECTED]> wrote:
> Dustin S wrote:
> > I've got a homepage right now with a few links that each use an
> > Ajax.Updater to XHR-in some content that gets shoved into the middle
> > of my page. I'm wondering how to gracefully handle two things:
>
> > (1) Users with normal browsers (i.e. JavaScript capable) who want to
> > direct link to some content on my page,http://www.foo.com/#direct_content
>
> > (2) How to properly handle non-JS browsers and still allow them to be
> > able to see the content as well.
>
> > The "web 2.0" solution I've had so many people try to sell to me so
> > far is to use careful "display:none;" and "show/hide" combinations to
> > just show and hide my content, with it all actually on my page. This
> > would mean I'm not XHRing the stuff in from somewhere else, though,
> > and the end result is an extremely heavyweight page (unacceptable).
>
> > -d
>
> We were just discussing this type of unobtrusiveness in the office. :)
> For your case, you may want to consider using frames or an iframe. If
> your system gets any more complicated or you want to do something like
> modal windows, the following approach works well:
>
>
> View some content
>
>
> $$('a.ajax').invoke('observe', 'click', function(event) {
> var element = event.element();
> var url = element.href + (element.href.indexOf('?') > -1 : '&' : '?')
> + 'ajax=1';
> new Ajax.Updater('middlePageContent', url);
> event.stop();});
>
>
>
> page/with/content.php:
> //..
> if ($_REQUEST['ajax'] != 1) include 'htmlHeader.php';
> echo $pageContent;
> if ($_REQUEST['ajax'] != 1) include 'htmlFooter.php';
> ?>
>
> You basically code the pages to work without JavaScript, but then
> observe each with a certain class. The observer stops the default
> action (going to the page) and runs an Ajax.Updater request. The server
> side page then just needs to skip output of the html header and footer
> if the request is from an XMLHttpRequest.
>
> - Ken Snyder
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: How to handle non-JavaScript browsers when using Ajax.Updaters for content
Dustin S wrote:
> I've got a homepage right now with a few links that each use an
> Ajax.Updater to XHR-in some content that gets shoved into the middle
> of my page. I'm wondering how to gracefully handle two things:
>
> (1) Users with normal browsers (i.e. JavaScript capable) who want to
> direct link to some content on my page, http://www.foo.com/#direct_content
>
> (2) How to properly handle non-JS browsers and still allow them to be
> able to see the content as well.
>
> The "web 2.0" solution I've had so many people try to sell to me so
> far is to use careful "display:none;" and "show/hide" combinations to
> just show and hide my content, with it all actually on my page. This
> would mean I'm not XHRing the stuff in from somewhere else, though,
> and the end result is an extremely heavyweight page (unacceptable).
>
> -d
We were just discussing this type of unobtrusiveness in the office. :)
For your case, you may want to consider using frames or an iframe. If
your system gets any more complicated or you want to do something like
modal windows, the following approach works well:
View some content
$$('a.ajax').invoke('observe', 'click', function(event) {
var element = event.element();
var url = element.href + (element.href.indexOf('?') > -1 : '&' : '?')
+ 'ajax=1';
new Ajax.Updater('middlePageContent', url);
event.stop();
});
page/with/content.php:
You basically code the pages to work without JavaScript, but then
observe each with a certain class. The observer stops the default
action (going to the page) and runs an Ajax.Updater request. The server
side page then just needs to skip output of the html header and footer
if the request is from an XMLHttpRequest.
- Ken Snyder
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
