Don't want to sound like I'm pushing my own wishlist (though this is
up there on mine) but I consider browser history support to be a
critical for RIA and usability. AJAXy apps have hijacked native
browser navigation/bookmarking facilities.
Whether or not this belongs in the core, I am not sure. I say this
because even though I feel that this feature should be available to
all developers, I understand the core is additive and once moved into
the core, it will have to stay there. And again, it's not the DOM. At
the same time however, I feel that allowing developers to conveniently
update url fragement with a single function
(.state('view-thread-456')) call can change the RIA landscape by
allowing developers to preserve state. In turn this will return native
browser navigation controls back to the user.
-- Aleem
On Wed, Feb 25, 2009 at 2:26 AM, John Resig <jere...@gmail.com> wrote:
>
> Ok, so boiling down a list:
>
> Needs code:
> - Widget utility (I'm working on this)
> - Debugging utility
> - Static plugin analyzer
>
> Need a tutorial to cover the concepts of (I'm working on this):
> - Encapsulation
> - Extensibility
> - Modularity
>
> Needs (defined/documented) conventions:
> - File names
> - Method names
> - Method structures
> - Testing
> - Documentation
> - Packaging
>
> Once the above conventions are finalized, that static plugin analyzer
> can be written.
>
> Once the widget code is done, the tutorial needs to be updated.
>
> ---
>
> So, with that drawn in the sand, Justin, would you be interested in
> working on the debugging plugin, the static analyzer, defining
> conventions, all of the above?
>
> Any/all of those would be a huge help and I'd imagine that if the work
> is solid they should all become official jQuery projects/conventions.
>
> Now I'm not discounting any additional code or patterns but we need to
> start with what we have and make sure that we're working with the best
> possible resources. If we define the above conventions and code we may
> find that there is less of a need for a new project than we originally
> thought - and we get the benefit of having excellently defined and
> documented resources and conventions for people to use - so everyone
> wins.
>
> --John
>
>
>
> On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer <justinbme...@gmail.com> wrote:
>>
>>> - package and minimize multiple files (YUI Compressor)
>>
>> - Could be solved much better as it is not integrated into the
>> 'framework'. You have to 'double' include everything (once in your
>> page, another in your build script). You have to set your html to
>> switch from loading separate files to loading the combined in
>> production.
>>
>>> - documentation (jQuery Documentation Wiki - already allows devs to
>>> have inline demos and can be extracted to external sources)
>>
>> Unless I am misunderstanding something, does this allow me to document
>> my application, or is this just for jQuery? I am talking about
>> something similar to JSDoc.
>>
>>> - testing (QUnit)
>>
>> Does it handles synthetic events? Can it run server-side to ensure
>> sanity before checkin? Can you do point and click testing like
>> selenium?
>>
>>> > Where do I put the files?
>>> > What should I name the files?
>>>
>>> I'm not completely convinced that this is a huge problem - but at
>>> worst this could be solved through convention and documentation.
>>>
>>> > How/where should I respond to events?
>>> > How should I deal with state?
>>> > How can I maximize the chances of re-usability?
>>>
>>> All three of these are handled either through better documentation or
>>> with the widget/jQuery.plugin code that I showed earlier (it
>>> especially helps to deal with state and reusability, while responding
>>> to events would be more of a documentation issue).
>>
>> Yes, these conventions are exactly what is needed. Documentation can
>> definitely do that, but so far I've not seen it for jQuery.
>>
>>> > Where should I be connecting to the service?
>>>
>>> That's probably outside the scope of anything that we would do, since
>>> it would probably define what needs to happen on the server-side.
>>
>> I mean, where should ajax calls happen in the client? In JMVC they
>> are in the Model, akin to ORM.
>>
>>> > How can I wrap the service data? (For example, maybe the todo has
>>> > passed it's completion date and you want to ask it .isPastDue().
>>>
>>> This seems like another case of encapsulation or dealing with state (imo).
>>>
>>> > How can I create HTML in a readable manner?
>>>
>>> At best, something that's done through convention.
>>
>> Yes, but where should that html go, etc. Yes, convention is needed.
>> I guess that is the central point we've arrived at.
>>
>> >
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
