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:
> > -----
> > <?php echo $content ?>
>
> > htmlHeadAndFootAndNav.phtml:
> > -----
> > <html>
> > <head>...</head>
> > <body>
> > <div id="page">
> >   <div id="header">
> >     <div id="navigation">...</div>
> >   </div>
> >   <div id="content">
> >     <?php echo $content ?>
> >   </div>
> > </div>
> > </body>
> > </html>
>
> > myContent.phtml:
> > -----
> > <?php ob_start() ?>
>
> > <p>Content...</p>
>
> > <?php
> > $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
-~----------~----~----~----~------~----~------~--~---

Reply via email to