Hi Jakub, response inline:
On Mon, May 25, 2009 at 12:46 PM, Jakub <[email protected]> wrote:
>
> HI Chris,
>
> Sounds interesting. Although I am not a hard core developer, so some
> of the terms like "routing" and "dependency injection" sound like
> black magic to me, I still have a feeling there could be some overlap
> here. Here is how I understand it along with where I am possibly going
> with fluidIA.
Sure, actually it can be overwhelming to have too much pattern-speak,
especially when it's a complex sounding terms that really means something
simple. I'll try to avoid throwing too much of those terms in.
Routing is actually pretty common, and really just means that there is a
collection of low-level application controllers that actually subscribe to
all the application defined events, and they 'route' the events to the
high-level, or custom, controllers. There are two good reasons to do this:
1) it allows all application events to be defined in a single location which
makes it very easy for collaborators to see all the applications event
wiring. 2) once an app gets a little bigger, say you have 50 custom
controllers, you don't have to create (instantiate) the controllers and bind
them to events at start-up time. The 'routers' are created, they bind to
the events, and they create the custom controllers only when required which
makes the app footprint smaller and startup much faster.
dependency inject is rarely used actually, it's more common to use
'scanners' which look under registered namespaces and provide lazy access to
application objects. jquery-claypool uses convention so that if
'MyApp.Controllers.Foo' is a function then $.$('#fooController') will return
an application managed instance of that function, creating it the first
time. 'MyApp.Views.Foo' is accessible with $.$('#fooView') and is a jQuery
object attached to the element with id='foo'.
>
>
> Taking the MVC approach, on occasion, a fluidIA object could be
> toggled to become a view. This would imply that the fluidIA object
> would still retain its existence on a page, and retain it's size and
> position properties. However the contents of the objects would be
> somehow linked to server side (server side js, php, rails, etc) or
> client side code (Javascript, or simply HTML).
Probably linked to a client-side event handler (controller) and html element
(view), while the server-side data is pulled with ajax (model). A great
example is a collaborator whats to add a dynamic table widget that is
populated from json, and lets you edit to table data.
> Here is perhaps the
> interested thing: if a fluidIA object becomes switched to a "view"
> then all of the objects's instances would call up on that logic and be
> reused.
absolutely. the event handlers (controllers) are not singletons, but
managed by the framework so that only one is ever created. Views can
actually be bound to multiple elements, for example think of a pagination
element that occurs at the top and bottom of a page of search results, both
use the same instance to be rendered and controlled.
> Here is what is a bit uncertain to me. I am thinking to
> possibly allow the setting of event handlers in the fluidIA
> environment itself that would perhaps act as controllers to switch
> between pages or switch fluidIA object states. Is this something that
> would conflict with how you would approach it?
I don't think so. I'm trying to look at fluidIA so I can better understand
what your asking here. In general what you are describing is very much why
I think jquery-claypool fits nicely. I think the analogy I keep visualizing
is using the adobe flash ide to create a widget-style app, so yes, allowing
them to write the event handlers as part of the fluidIA interface is a
perfect fit for jquery-claypool.
>
>
> Perhaps I am not using proper development terms, as I am more of a
> designer. Do you think claypool could help achieve this?
i do
>
>
> Please let me know what you think. Or perhaps why you think fluidIA +
> claypool is a good combo. :)
jquery-claypool provides a very light and flexible framework for
jquery/jquery-ui similar to many framework patterns built-in to the flash
development environment and tool chain. when you are using the flash tool
chain, the ide or hand writing against the api's, you are using something
like jquery-claypool to minimize how much work you need to do to add a new
feature, find a feature, reuse existing features, etc. most importantly,
following a couple conventions allows collaborators to efficiently discover
features and contribute effectively as soon as possible.
>
>
> Cheers,
> Jakub
>
Hope this clarifies why it would be a good fit.
Thatcher
>
>
> On May 24, 11:46 pm, chris thatcher <[email protected]>
> wrote:
> > Jakub, I have an open source project that is supposed to provide some
> > railable patterns to jquery/jquery ui. The on-going idea is to provide
> some
> > very general patterns to allow ui development to become more automated.
> > jquery-claypool provides mvc, routing, lazy loading, dependency
> injection,
> > filters (aop), category logging, convention-over-configuration, while not
> > requiring any sort of inheritence dependencies. It very light weight and
> > even supports server-side development. My real goal for it has been for
> > minimal generated code to allow flexible ui or commandline integration
> with
> > jquery-ui/jquery, like flash/flex for jquery, while still adhering to the
> > jquery-way as much as possible. jquery-claypool is not jquery or
> jquery-ui,
> > nor is it what your doing, but it strongly compliments their goals
> without
> > duplicating them.
> >
> >
> http://github.com/thatcherhttp://claypooljs.comhttp://docs.jquery.com/Plugins/Claypool
> >
> > It very stable, very minimal, very extensible, and very understable for
> > folks who come from application framework backgrounds like django, rails,
> > spring, etc. It was very recently releases as a 1.0 though I've used it
> for
> > about a year and a half in development and it will be released with a
> > library of congress production project in about 12 days.
> >
> > I will contribute effort if you decide to use it.
> >
> > Thanks,
> > Thatcher
> >
> >
> >
> > On Sun, May 24, 2009 at 8:00 PM, Jakub <[email protected]> wrote:
> >
> > > Thanks Paul. :)
> >
> > > On May 21, 10:49 pm, Paul Bakaus <[email protected]> wrote:
> > > > Hey Jakub,
> >
> > > > this looks really cool! I'm cc'ing my friend Tom here, since he had a
> > > very
> > > > similar idea
> > > > some time ago, and I'm sure he's interested in learning more about
> your
> > > > approach.
> >
> > > > Cheers,
> > > > Paul
> >
> > > > On Fri, May 22, 2009 at 9:13 AM, Jakub <[email protected]> wrote:
> >
> > > > > Hello,
> >
> > > > > A year ago, on a part time basis I started an open source user
> > > > > interface prototyping project -www.fluidIA.org. Recently this
> turned
> > > > > into a grad project. Seeing the powerful potential of jQuery, I've
> > > > > relied on this Javascript library to build this browser based
> > > > > application. The tool aims to empower interaction designers and
> > > > > developers to quickly generate wireframes/prototypes, and more so,
> > > > > allows for rapid refinement through object orientation and
> > > > > inheritance. Support for state based objects has also been already
> > > > > implemented. A working Firefox copy is running over at:
> > > > >http://stage.fluidia.org
> >
> > > > > For the fluidIA project, one of my upcoming tasks is also to
> explore
> > > > > the ability to create a UI for jQuery's event handling
> capabilities.
> > > > > In turn, this could result in something of a WYSIWYG editor for
> event
> > > > > based interactions. However, for more powerful logic and data
> binding,
> > > > > the environment will also support the ability to toggle fluidIA
> > > > > objects and replace them with "real" code, should developers wish
> to
> > > > > program the desired interactions. In a way then, these objects can
> act
> > > > > as guiding or exploratory ideas which would then evolve to proper
> > > > > code. Here are two very rough sketches of this:
> > > > >http://fluidia.org/wp/?p=192(toggle)<http://fluidia.org/wp/?p=192%28toggle%29>
> > > > >http://fluidia.org/wp/?p=94(low-fi<http://fluidia.org/wp/?p=94%28low-fi>events)
> >
> > > > > So why am I writing about all this here? Well, so far I've been a
> one
> > > > > man army doing design, development and recently user testing. Just
> > > > > thought to throw the project up here should there be any interested
> > > > > developers / designers in participating. I'm really a generalist
> > > > > (visual and interaction designer by education), and thought it
> would
> > > > > be cool to work with some pro developers on this.
> >
> > > > > 1. So far I've opened the source over at:
> > > > >http://github.com/fluidia/fluidia/tree/master
> >
> > > > > 2. I have also opened up the design process:
> > > > >http://fluidia.org/wp/?category_name=sketches
> > > > > where I am interested in contributions from others as well. (Am
> really
> > > > > interested in running an open source + open design project and see
> how
> > > > > designers could collaborate with developers.)
> >
> > > > > 3. Google Groups:http://groups.google.com/group/fluidia
> >
> > > > > Should any jQuery gurus be interested in working on this project,
> > > > > please let me know. Would love to hear from you.
> >
> > > > > Cheers,
> > > > > Jakub Linowski
> > > > >www.fluidia.org
> > > > >www.linowski.ca
> >
> > > > --
> > > > Paul Bakaus
> > > > UI Architect
> > > > --http://paulbakaus.comhttp://www.linkedin.com/in/paulbakaus
> >
> > --
> > Christopher Thatcher
> >
>
--
Christopher Thatcher
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
