ExtJs Development

[Will Shaver]

I've seen a number of comments on the codeplex site regarding ExtJs,
but don't see any code or discussion regarding it on this group. Has
anyone started work on this? I'm likely to do so for a project I'm
working on anyway, and intend to contribute as I develop useful tools.

-Will

[Nermin Dibek]

Well there is a MVC Javascipt project, led by Justice Gray, Adam Tybor and Sergio Pereira.

 

They might be forking their code away from MVCCOntrib and have a separate project on Assembla:

 

http://graysmatter.codivation.com/PermaLink,guid,8b184e19-a585-4249-b392-1b7bc5703bd9.aspx 

[Adam Tybor]

> Well there is a MVC Javascipt project, led by Justice Gray, Adam Tybor and
> Sergio Pereira.

A couple of us have gotten together to start working on Client Script
support for asp.net mvc. John Teague, Sergio Pereira, and myself.
Justice is on a leave of absence for now as he doesn't have the time
to commit to the project. The code is in a private branch. We keep
it in sync with contrib trunk so merging should be a non issue.

> They might be forking their code away from MVCCOntrib and have a separate
> project on Assembla:

The idea of forking into a separate project has come up and I am in
favor of it for a couple of reasons.

1) We would be able to open it up to different commiters than are
currently on the contrib project.

2) The core of the project is reusable and adapters could be written
to support other frameworks like monorail, and possibly asp.net
webforms. So the project has the potential to grow beyond the scope
of mvc contrib.

The cons of being a separate project are marketing, visibility, and
internal politics of using open source code at the office. Anyone who
has issues with using open source software at the office will probably
have a shot at getting mvc contrib approved. As of right now I don't
know how you could use asp.net mvc without it. But after that it may
be difficult to get more projects and dll's included so I see a
significant benefit to staying aligned with contrib.


What are the goals of our project?
To produce a framework that allows you to add web 2.0 client side
functionality with minimal effort.

We will be javascript library agnostic, emit unobtrusive script where
possible, and make degrading for clients that do not support script
easy. Our api will be flexible. We will minimize the number of
context switches a developer has to make from server side code to
client side code by providing a ScriptBuilder with intellisense to
handle a large number of use cases. We will not stifle a developer
with our framework, if you want to hand write all your script, our api
certainly supports that too. The framework will be easy to extend
with your own custom javascript generator functions to handle specific
use cases so your views have less code, intellisense, and refactoring
support.

We currently have dom support and a sample of ajax working across
prototype, jquery, and extjs. The api supports fluent interfaces,
anonymous delegates, and webcontrols as options for using it. Whether
you are a vb dev, c# dev, a code guy or a control guy the library
should be usable.

So I will put the question out to the community, fork it or keep it in
contrib?

I should be speaking with Jeff early next week and I will ask for his
opinion as well.

If you are interested in helping out, shoot John or myself an email
and we can go from there. We are looking for someone with extjs
experience as that is a library where we have the least experience and
the model is very different from prototype and jquery.

Adam

On Jan 31, 3:47 pm, "Nermin Dibek" <ndi...@gmail.com> wrote:
> Well there is a MVC Javascipt project, led by Justice Gray, Adam Tybor and
> Sergio Pereira.
>
> They might be forking their code away from MVCCOntrib and have a separate
> project on Assembla:
>

> http://graysmatter.codivation.com/PermaLink,guid,8b184e19-a585-4249-b...

[Jeffrey Palermo]

I completely support this idea, and the committer list for MvcContrib
is not a closed one. For instance, it's completely possible to have a
small group of committers focused on one piece of MvcContrib (if this
initiative were to become one piece). MvcContrib is heterogeneous
enough to allow this. You should be able to use one feature and
ignore the rest of MvcContrib if you wish. Using one feature will not
force you to use all features. I would welcome this code (and your
committers) if and when you decide that working within MvcContrib is
appropriate.

--
Best regards,
Jeffrey Palermo, Microsoft MVP, MCSD.Net
CTO, Headspring Systems
512-459-2260 x 712

[DragonFist]

Personally, I would like to see this project be part of the MVC
Contrib project if for no other reason than I don't need another url I
need to remember to get my MVC data fix.

On Feb 6, 9:46 am, "Jeffrey Palermo" <Jeff...@Palermo.cc> wrote:
> I completely support this idea, and the committer list for MvcContrib
> is not a closed one.  For instance, it's completely possible to have a
> small group of committers focused on one piece of MvcContrib (if this
> initiative were to become one piece).  MvcContrib is heterogeneous
> enough to allow this.  You should be able to use one feature and
> ignore the rest of MvcContrib if you wish.  Using one feature will not
> force you to use all features.  I would welcome this code (and your
> committers) if and when you decide that working within MvcContrib is
> appropriate.
>
> --
> Best regards,
> Jeffrey Palermo, Microsoft MVP, MCSD.Net
> CTO, Headspring Systems
> 512-459-2260 x 712
>

> > > >  -Will- Hide quoted text -
>
> - Show quoted text -