Hi Grant
>> In that example what I have found is that I tend to break the
>> functionality down into smaller pieces that (for instance) just update
>> small pieces of the view, or manipulate sections of the data.
>
> Ahh, I see what you mean. Not so much more complex actions for Ajax,
> rather
> In that example what I have found is that I tend to break the
> functionality down into smaller pieces that (for instance) just update
> small pieces of the view, or manipulate sections of the data.
Ahh, I see what you mean. Not so much more complex actions for Ajax,
rather more specific actio
Hi Grant
>> Sure. The apps that I have created that use AJAX use it to combine
>> - A production Batch
>> -- Its Operations
>> --- Each Operation's Inputs and Outputs
>> Each Output's Storage Instances
>> The best comparison would be something like Windows Explorer with the
>> tree displaye
Hi Langdon,
> Sure. The apps that I have created that use AJAX use it to combine
> - A production Batch
> -- Its Operations
> --- Each Operation's Inputs and Outputs
> Each Output's Storage Instances
> The best comparison would be something like Windows Explorer with the
> tree displayed on
Hi Grant
> Langdon - I am still in two minds as to whether a non-Javascript
> version is really necessary. Because if it is, then I'll need to
> write some alternative functionality in some places. But being able
> to use the app on my mobile phone really does sounds neat.
> Can you expand on w
Hi Samuel
>>> and is more likely to work when javascript is disabled ;)
>>
>> This is meant to be a dig at me? :-)
>>
>
> Not at all, I was simply trying to say that if one develops the
> non-ajax workflow first. It is more likely that as one adds ajax to
> the flow that things will continue t
On 5/10/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote:
>
> Hi Samuel
>
> > and is more likely to work when javascript is disabled ;)
>
> This is meant to be a dig at me? :-)
>
Not at all, I was simply trying to say that if one develops the
non-ajax workflow first. It is more likely that as one
Langdon - I am still in two minds as to whether a non-Javascript
version is really necessary. Because if it is, then I'll need to
write some alternative functionality in some places. But being able
to use the app on my mobile phone really does sounds neat.
Can you expand on what Ajax specific ac
Hi Grant,
Let me show You some sweet features of CakePHP 1.2, please...
1. CakePHP 1.2 can parse 'file extensions' in url so RequestHandler
component can send proper headers and also customize helpers, viewPath
and layoutPath properties of controller. By the other words: if Your
ajax request wil
Hi Samuel
> and is more likely to work when javascript is disabled ;)
This is meant to be a dig at me? :-)
If so, then let me clarify a little. If I can't guarantee that
javascript is available, then I won't require it, either by providing a
regular get/post alternative, or not using AJAX at
and is more likely to work when javascript is disabled ;)
On 5/9/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote:
>
> Hi Grant
>
> > Now, rather than describe what I have implemented for this, I am
> > looking to hear what others have done in this situation. I don't want
> > to taint your voices
Hi Grant
> Now, rather than describe what I have implemented for this, I am
> looking to hear what others have done in this situation. I don't want
> to taint your voices with my opinion, yet :P Surely there are a
> number of applications that have both a "plain HTML" and Ajax enabled
> version
Our application has finally reached a point where we are designing the
final UI. Up until now we've kept to the cake standard, where all
actions have their own HTML view, with minimal javascript (only for
required functionality). This of course lends itself to a lot of page
reloading and changin
13 matches
Mail list logo
