Hi!
It seems like a simple problem, but it is not (to day, I have not been
able to find a way to do this without complex javascript coding):
You have chained comboboxes: County and State.
You select USA in the Country combobox, and its 50 States are loaded
in the States Combo (roundtrip to the server to fetch them)
You select Mexico in the Country combobox, and its 32 States are
loaded in the States Combo (roundtrip to the server to fetch them)
Now you select USA in the Country combobox again... how do I tell
Ariba that I do not want it to go to the server for them, since it
went for them the last time I selected USA, I want it to use that as a
cache and do not go for them until I tell it to do so?
We wouldn't call it an "omission" as much as a "design choice"... :-)
We don't cache this data on the client because, in the general case,
we can't detect that it's statically cacheable. (e.g. your code may
be filtering this list the second time around based on other
selections on the page or other changes in server-side state). In
practice we have not found this to be a significant issue in
application responsiveness or user experience.
> want it to use that as a
> cache and do not go for them until I tell it to do so?
That last part is exactly the issue: we don't want your programming
burdened with needing to "tell it to do so" -- this leads to a lot
more code and a lot more opportunities for errors.
> Hi!
> It seems like a simple problem, but it is not (to day, I have not been
> able to find a way to do this without complex javascript coding):
> You have chained comboboxes: County and State.
> You select USA in the Country combobox, and its 50 States are loaded
> in the States Combo (roundtrip to the server to fetch them)
> You select Mexico in the Country combobox, and its 32 States are
> loaded in the States Combo (roundtrip to the server to fetch them)
> Now you select USA in the Country combobox again... how do I tell
> Ariba that I do not want it to go to the server for them, since it
> went for them the last time I selected USA, I want it to use that as a
> cache and do not go for them until I tell it to do so?
All right, so it is not possible to do it now... (and by what you
said, it will not be possible to do it in the near future)
Now, lets say I have already built my app using Ariba and I have a
very important ($$$) customer that really wants this feature (you
probably know how irrational some customers can be about some
features).
What would you recommend me to do to make my customer happy? Perhaps
creating an specially designed "combobox tree control" with inherent
caching/chaining capabilities encapsulated inside it?
Would it be hard to create such a "low level" new control in AribaWeb?
Regards,
LuxSpes
On Feb 24, 10:03 am, Craig Federighi <craig.federi...@gmail.com>
wrote:
> We wouldn't call it an "omission" as much as a "design choice"... :-)
> We don't cache this data on the client because, in the general case,
> we can't detect that it's statically cacheable. (e.g. your code may
> be filtering this list the second time around based on other
> selections on the page or other changes in server-side state). In
> practice we have not found this to be a significant issue in
> application responsiveness or user experience.
> > want it to use that as a
> > cache and do not go for them until I tell it to do so?
> That last part is exactly the issue: we don't want your programming
> burdened with needing to "tell it to do so" -- this leads to a lot
> more code and a lot more opportunities for errors.
> Thanks!
> - craig
> On Feb 24, 2009, at 7:26 AM, luxspes wrote:
> > Hi!
> > It seems like a simple problem, but it is not (to day, I have not been
> > able to find a way to do this without complex javascript coding):
> > You have chained comboboxes: County and State.
> > You select USA in the Country combobox, and its 50 States are loaded
> > in the States Combo (roundtrip to the server to fetch them)
> > You select Mexico in the Country combobox, and its 32 States are
> > loaded in the States Combo (roundtrip to the server to fetch them)
> > Now you select USA in the Country combobox again... how do I tell
> > Ariba that I do not want it to go to the server for them, since it
> > went for them the last time I selected USA, I want it to use that as a
> > cache and do not go for them until I tell it to do so?
> Now, lets say I have already built my app using Ariba and I have a
> very important ($$$) customer that really wants this feature (you
> probably know how irrational some customers can be about some
> features).
Well, we have millions of users from a large fraction of the (very
demanding) Global 2000, so we've managed to satisfy a pretty broad
swath of your potential customer base on this count.
Here's what I'd try with your customer:
1) Your users are most affected by "common case" performance, not edge
case optimizations.
2) 80% of the time they will either A) select US, and pick a state, or
B) Select US, then Select Mexico, then pick a state. Their perception
of app performance will be based on how well the server handles those
common case operations. (The app must be capable of performing those
operations with acceptably low latency, or your users will be unhappy).
3) Given that you've satisfied your users in the common case #2, then
the edge case (C) of select US, select Mexico, then select US must
meet their expectations: it will perform as least as fast as the
common case (without additional caching).
[Now, I know that you provided this use case as just one illustration
of a broader class of client side caching scenarios. I too offer the
reasoning above as largely applicable to most cases where users think
they need client-side caching. In practice, we've found this
reasoning to be sound across a wide range of business applications].
> Would it be hard to create such a "low level" new control in AribaWeb?
It wouldn't be all that hard to do, but you'd be writing some
JavaScript. (I'd tell your client that you'd be better off applying
all the time you saved using AribaWeb instead to building out more
business functionality! ;-)
> All right, so it is not possible to do it now... (and by what you
> said, it will not be possible to do it in the near future)
> Now, lets say I have already built my app using Ariba and I have a
> very important ($$$) customer that really wants this feature (you
> probably know how irrational some customers can be about some
> features).
> What would you recommend me to do to make my customer happy? Perhaps
> creating an specially designed "combobox tree control" with inherent
> caching/chaining capabilities encapsulated inside it?
> Would it be hard to create such a "low level" new control in AribaWeb?
> Regards,
> LuxSpes
> On Feb 24, 10:03 am, Craig Federighi <craig.federi...@gmail.com>
> wrote:
>> Hi LuxSpecs,
>> We wouldn't call it an "omission" as much as a "design choice"... :-)
>> We don't cache this data on the client because, in the general case,
>> we can't detect that it's statically cacheable. (e.g. your code may
>> be filtering this list the second time around based on other
>> selections on the page or other changes in server-side state). In
>> practice we have not found this to be a significant issue in
>> application responsiveness or user experience.
>>> want it to use that as a
>>> cache and do not go for them until I tell it to do so?
>> That last part is exactly the issue: we don't want your programming
>> burdened with needing to "tell it to do so" -- this leads to a lot
>> more code and a lot more opportunities for errors.
>> Thanks!
>> - craig
>> On Feb 24, 2009, at 7:26 AM, luxspes wrote:
>>> Hi!
>>> It seems like a simple problem, but it is not (to day, I have not
>>> been
>>> able to find a way to do this without complex javascript coding):
>>> You have chained comboboxes: County and State.
>>> You select USA in the Country combobox, and its 50 States are loaded
>>> in the States Combo (roundtrip to the server to fetch them)
>>> You select Mexico in the Country combobox, and its 32 States are
>>> loaded in the States Combo (roundtrip to the server to fetch them)
>>> Now you select USA in the Country combobox again... how do I tell
>>> Ariba that I do not want it to go to the server for them, since it
>>> went for them the last time I selected USA, I want it to use that
>>> as a
>>> cache and do not go for them until I tell it to do so?
Hi!
First, thanks for you answers so far!
You are right I provided this use case as just one illustration
of a broader class of client side caching scenarios, and you resoning
works fine... for particular kind of use case, for example for user
registration... sadly, I do not build that kind of application where I
work now, the kind of application I have to build is the kind where
the UI is used repeatedly, the kind where the user is not someone in
his house registering himself and only himself... yes, I build those
dreaded "enterprise level" applications used internally:
Say you have someone answering the phone and filling this information,
this person answers phone for several different countries, and needs
to capture this information during each phone call, so, he typically
select USA, and then Mexico, and then France, and the USA, and then UK
and then.... and he has a really slow network connection... so he
really doesn't like to wait those 3 or 5 seconds after he selects the
country, so he complains to his boss, he complains to the IT
department, and the IT department says: "well, it needs to load those
States, that is why it takes time", but the user complains: "yes, but
with our previous system built with VB6 was only slow the first time I
selected a country, why the new system can not remember the states of
the country I selected 5 minutes ago, even if that country is having a
civil war it can not be changing its political structure every 5
minutes"
So you are left (AFAIK) with no arguments.... (BTW have you noticed
that chained combo boxes are very common, but a control to easy handle
them is never pre-packaged as a widget?)...
I wonder... Is this problem really impossible to solve in a
declarative way? is this really the unsurmountable frontier for server
based frameworks? I could some trick be built that worked? Perhaps by
storing in the client snapshots of previous states of the UI and then
telling some part of the UI to re-sync with them?
Thanks
Regards,
LuxSpes
On Feb 24, 12:18 pm, Craig Federighi <craig.federi...@gmail.com>
wrote:
> > Now, lets say I have already built my app using Ariba and I have a
> > very important ($$$) customer that really wants this feature (you
> > probably know how irrational some customers can be about some
> > features).
> Well, we have millions of users from a large fraction of the (very
> demanding) Global 2000, so we've managed to satisfy a pretty broad
> swath of your potential customer base on this count.
> Here's what I'd try with your customer:
> 1) Your users are most affected by "common case" performance, not edge
> case optimizations.
> 2) 80% of the time they will either A) select US, and pick a state, or
> B) Select US, then Select Mexico, then pick a state. Their perception
> of app performance will be based on how well the server handles those
> common case operations. (The app must be capable of performing those
> operations with acceptably low latency, or your users will be unhappy).
> 3) Given that you've satisfied your users in the common case #2, then
> the edge case (C) of select US, select Mexico, then select US must
> meet their expectations: it will perform as least as fast as the
> common case (without additional caching).
> [Now, I know that you provided this use case as just one illustration
> of a broader class of client side caching scenarios. I too offer the
> reasoning above as largely applicable to most cases where users think
> they need client-side caching. In practice, we've found this
> reasoning to be sound across a wide range of business applications].
> > Would it be hard to create such a "low level" new control in AribaWeb?
> It wouldn't be all that hard to do, but you'd be writing some
> JavaScript. (I'd tell your client that you'd be better off applying
> all the time you saved using AribaWeb instead to building out more
> business functionality! ;-)
> Thanks,
> - craig
> On Feb 24, 2009, at 9:44 AM, luxspes wrote:
> > All right, so it is not possible to do it now... (and by what you
> > said, it will not be possible to do it in the near future)
> > Now, lets say I have already built my app using Ariba and I have a
> > very important ($$$) customer that really wants this feature (you
> > probably know how irrational some customers can be about some
> > features).
> > What would you recommend me to do to make my customer happy? Perhaps
> > creating an specially designed "combobox tree control" with inherent
> > caching/chaining capabilities encapsulated inside it?
> > Would it be hard to create such a "low level" new control in AribaWeb?
> > Regards,
> > LuxSpes
> > On Feb 24, 10:03 am, Craig Federighi <craig.federi...@gmail.com>
> > wrote:
> >> Hi LuxSpecs,
> >> We wouldn't call it an "omission" as much as a "design choice"... :-)
> >> We don't cache this data on the client because, in the general case,
> >> we can't detect that it's statically cacheable. (e.g. your code may
> >> be filtering this list the second time around based on other
> >> selections on the page or other changes in server-side state). In
> >> practice we have not found this to be a significant issue in
> >> application responsiveness or user experience.
> >>> want it to use that as a
> >>> cache and do not go for them until I tell it to do so?
> >> That last part is exactly the issue: we don't want your programming
> >> burdened with needing to "tell it to do so" -- this leads to a lot
> >> more code and a lot more opportunities for errors.
> >> Thanks!
> >> - craig
> >> On Feb 24, 2009, at 7:26 AM, luxspes wrote:
> >>> Hi!
> >>> It seems like a simple problem, but it is not (to day, I have not
> >>> been
> >>> able to find a way to do this without complex javascript coding):
> >>> You have chained comboboxes: County and State.
> >>> You select USA in the Country combobox, and its 50 States are loaded
> >>> in the States Combo (roundtrip to the server to fetch them)
> >>> You select Mexico in the Country combobox, and its 32 States are
> >>> loaded in the States Combo (roundtrip to the server to fetch them)
> >>> Now you select USA in the Country combobox again... how do I tell
> >>> Ariba that I do not want it to go to the server for them, since it
> >>> went for them the last time I selected USA, I want it to use that
> >>> as a
> >>> cache and do not go for them until I tell it to do so?
I understand where you are coming from, and it is certainly possible
to build a client-side caching multi-level chooser control in AW
(particularly it the choosers are essentially navigating a static
hierarchy). That said, we are finding that incidences of the "slow
network connection with 3-5 second latencies"), while common years
ago, are much less so now: particularly for data entry workers doing
repeated data entry from their primary terminal.
Gziped (as AW responses typically are in a production configuration),
a list of 50 states in HTML <option> form, is 553 bytes. That's a
single packet, with a single network round trip. From my home DSL (in
California) my ping time to China is 220 ms. Even with satellite
links latency over 1.5 sec is becoming rare.
Long and short:
- Yes, the client situation you describe can exist, but is (in our
experience) becoming increasingly rare
- AW is an open system: you are free to drop down into JavaScript and
build a custom component for caching multilevel choosers, if you must.
> Hi!
> First, thanks for you answers so far!
> You are right I provided this use case as just one illustration
> of a broader class of client side caching scenarios, and you resoning
> works fine... for particular kind of use case, for example for user
> registration... sadly, I do not build that kind of application where I
> work now, the kind of application I have to build is the kind where
> the UI is used repeatedly, the kind where the user is not someone in
> his house registering himself and only himself... yes, I build those
> dreaded "enterprise level" applications used internally:
> Say you have someone answering the phone and filling this information,
> this person answers phone for several different countries, and needs
> to capture this information during each phone call, so, he typically
> select USA, and then Mexico, and then France, and the USA, and then UK
> and then.... and he has a really slow network connection... so he
> really doesn't like to wait those 3 or 5 seconds after he selects the
> country, so he complains to his boss, he complains to the IT
> department, and the IT department says: "well, it needs to load those
> States, that is why it takes time", but the user complains: "yes, but
> with our previous system built with VB6 was only slow the first time I
> selected a country, why the new system can not remember the states of
> the country I selected 5 minutes ago, even if that country is having a
> civil war it can not be changing its political structure every 5
> minutes"
> So you are left (AFAIK) with no arguments.... (BTW have you noticed
> that chained combo boxes are very common, but a control to easy handle
> them is never pre-packaged as a widget?)...
> I wonder... Is this problem really impossible to solve in a
> declarative way? is this really the unsurmountable frontier for server
> based frameworks? I could some trick be built that worked? Perhaps by
> storing in the client snapshots of previous states of the UI and then
> telling some part of the UI to re-sync with them?
> Thanks
> Regards,
> LuxSpes
> On Feb 24, 12:18 pm, Craig Federighi <craig.federi...@gmail.com>
> wrote:
>> Hi LuxSpecs,
>>> Now, lets say I have already built my app using Ariba and I have a
>>> very important ($$$) customer that really wants this feature (you
>>> probably know how irrational some customers can be about some
>>> features).
>> Well, we have millions of users from a large fraction of the (very
>> demanding) Global 2000, so we've managed to satisfy a pretty broad
>> swath of your potential customer base on this count.
>> Here's what I'd try with your customer:
>> 1) Your users are most affected by "common case" performance, not
>> edge
>> case optimizations.
>> 2) 80% of the time they will either A) select US, and pick a state,
>> or
>> B) Select US, then Select Mexico, then pick a state. Their
>> perception
>> of app performance will be based on how well the server handles those
>> common case operations. (The app must be capable of performing those
>> operations with acceptably low latency, or your users will be
>> unhappy).
>> 3) Given that you've satisfied your users in the common case #2, then
>> the edge case (C) of select US, select Mexico, then select US must
>> meet their expectations: it will perform as least as fast as the
>> common case (without additional caching).
>> [Now, I know that you provided this use case as just one illustration
>> of a broader class of client side caching scenarios. I too offer the
>> reasoning above as largely applicable to most cases where users think
>> they need client-side caching. In practice, we've found this
>> reasoning to be sound across a wide range of business applications].
>>> Would it be hard to create such a "low level" new control in
>>> AribaWeb?
>> It wouldn't be all that hard to do, but you'd be writing some
>> JavaScript. (I'd tell your client that you'd be better off applying
>> all the time you saved using AribaWeb instead to building out more
>> business functionality! ;-)
>> Thanks,
>> - craig
>> On Feb 24, 2009, at 9:44 AM, luxspes wrote:
>>> All right, so it is not possible to do it now... (and by what you
>>> said, it will not be possible to do it in the near future)
>>> Now, lets say I have already built my app using Ariba and I have a
>>> very important ($$$) customer that really wants this feature (you
>>> probably know how irrational some customers can be about some
>>> features).
>>> What would you recommend me to do to make my customer happy?
>>> Perhaps
>>> creating an specially designed "combobox tree control" with inherent
>>> caching/chaining capabilities encapsulated inside it?
>>> Would it be hard to create such a "low level" new control in
>>> AribaWeb?
>>> Regards,
>>> LuxSpes
>>> On Feb 24, 10:03 am, Craig Federighi <craig.federi...@gmail.com>
>>> wrote:
>>>> Hi LuxSpecs,
>>>> We wouldn't call it an "omission" as much as a "design
>>>> choice"... :-)
>>>> We don't cache this data on the client because, in the general
>>>> case,
>>>> we can't detect that it's statically cacheable. (e.g. your code
>>>> may
>>>> be filtering this list the second time around based on other
>>>> selections on the page or other changes in server-side state). In
>>>> practice we have not found this to be a significant issue in
>>>> application responsiveness or user experience.
>>>>> want it to use that as a
>>>>> cache and do not go for them until I tell it to do so?
>>>> That last part is exactly the issue: we don't want your programming
>>>> burdened with needing to "tell it to do so" -- this leads to a lot
>>>> more code and a lot more opportunities for errors.
>>>> Thanks!
>>>> - craig
>>>> On Feb 24, 2009, at 7:26 AM, luxspes wrote:
>>>>> Hi!
>>>>> It seems like a simple problem, but it is not (to day, I have not
>>>>> been
>>>>> able to find a way to do this without complex javascript coding):
>>>>> You have chained comboboxes: County and State.
>>>>> You select USA in the Country combobox, and its 50 States are
>>>>> loaded
>>>>> in the States Combo (roundtrip to the server to fetch them)
>>>>> You select Mexico in the Country combobox, and its 32 States are
>>>>> loaded in the States Combo (roundtrip to the server to fetch
>>>>> them)
>>>>> Now you select USA in the Country combobox again... how do I tell
>>>>> Ariba that I do not want it to go to the server for them, since it
>>>>> went for them the last time I selected USA, I want it to use that
>>>>> as a
>>>>> cache and do not go for them until I tell it to do so?
Have you though about perhaps integrating with Cappuccino ( http://cappuccino.org/ ) to make building this
kind of client optimized widgets easier to build?
And the integrating with Besping ( https://bespin.mozilla.com/ ). OMG
my mind boggles thinking of the possibilities!!!!
On Feb 24, 3:26 pm, Craig Federighi <craig.federi...@gmail.com> wrote:
> I understand where you are coming from, and it is certainly possible
> to build a client-side caching multi-level chooser control in AW
> (particularly it the choosers are essentially navigating a static
> hierarchy). That said, we are finding that incidences of the "slow
> network connection with 3-5 second latencies"), while common years
> ago, are much less so now: particularly for data entry workers doing
> repeated data entry from their primary terminal.
> Gziped (as AW responses typically are in a production configuration),
> a list of 50 states in HTML <option> form, is 553 bytes. That's a
> single packet, with a single network round trip. From my home DSL (in
> California) my ping time to China is 220 ms. Even with satellite
> links latency over 1.5 sec is becoming rare.
> Long and short:
> - Yes, the client situation you describe can exist, but is (in our
> experience) becoming increasingly rare
> - AW is an open system: you are free to drop down into JavaScript and
> build a custom component for caching multilevel choosers, if you must.
|
