Hi all,
Who is interested in helping to work on CSLA .NET 4.0?
I know Sergey and Ricky are interested for sure –
Sergey with EF stuff, and Ricky with MVC stuff.
I’m not quite ready for a lot of help just yet. I’ve
done a bunch of structural reorg to the folder/solution/project structure. But
before a lot of people dig in too far there is one important task that needs to
get done:
Rename all the existing *ListBase classes to
*BindingListBase and create new *ListBase classes that inherit from
ObservableCollection<T> (probably by copying the SL classes to \core
since they already work – mostly at least)
The other relatively large-scale change is to create a
Csla.Rules namespace (I’m still debating the name) that will contain the new
business/validation rules subsystem – and maybe a consolidated
authorization rules subsystem. I want to clean up the “validation”
subsystem, because that is a poor description. Along the way I want to
consolidate sync and async rules so they work the same, and are probably
differentiated by an [AsyncRule] attribute on the rule method itself. If done
right, the result should be that async rules can safely alter the object state
(indirectly, upon completion) which would be pretty cool.
Rocky
Rockford Lhotka
Magenic -
Principal Technology Evangelist
Email | Blog | Web | CSLA .NET for
Windows | CSLA .NET for Silverlight
rxelizondo:
Just a quick question, how much knowledge does one has to have regarding the framework to be useful in helping out?
To be productive, quite a bit of knowledge is probably required. Otherwise common code doesn't get normalized, etc.
There's already a little of that issue (some duplicate reflection code for example), and that needs to be minimized.
For example, "renaming the *ListBase" classes isn't as easy as a simple rename (though even that is complicated due to subversion). There's some code in the existing BusinessListBase and EditableRootListBase that surely will also be in the new classes. The challenge will be to try and normalize as much of that common code as possible - keeping in mind that data binding is interface-based and we can't have a shared base class - so some code will almost certainly be duplicated.
And these classes (BLB in particular) participate in n-level undo, which is notoriously complex due to its interaction with data binding. So automated testing is good, but manual testing in Windows Forms datagrid controls is also required when messing with anything that touches undo.
In short, quite a bit of knowledge of the framework is required. I can provide insight into historical issues where necessary - helping (hopefully) to identify areas that require more extensive testing and caution.
Hi Rocky
How would you delegate the work? Would you give a basic overview of what you want to achieve and expect the developer to take a lot of initiative during implementation or would you want to provide more details (e.g. a spec?). I would probably be of some assistance if you plan to do the latter so for tasks like the *ListBase renaming, I'd be glad to offer as much assistance as possible.
Contributors must sign a legal agreement that establishes a
relationship between Marimer LLC (owner of the framework) and the contributor.
The primary element of the agreement is that Marimer LLC owns the code and
associated IP.
I can’t manage a lot of people, but some help is needed –
especially in areas where I know I won’t have time to pay attention
(Windows Forms may be the most notable, and also the idea of an installer, VS
templates – that whole area).
I’ll be honest about this – my expectations of
contributors are pretty high in terms of technical competence and in terms of holding
true to my vision for the framework. The last thing I need is to spend more
time teaching C# than doing the work, or fighting with someone who wants the
framework to be different than what I want it to be :)
Similarly, there are some coding standards to follow – the
goal with team coding (in my mind) is that it should be impossible to look at a
piece of code and tell who wrote it. Everyone on a team should code using exactly
the same style. That’s a hard one, but important.
Yes triplea, the basic idea would be to identify tasks that can
be implemented by a developer, spec it out via email or via LiveMeeting and to
have the developer be reasonably autonomous. That said, code reviews and
continual dialog are important aspects of the process.
Rocky
It is also the case that contributors need the VS10 Beta (and the ability to upgrade as new beta/RC releases come out) and Silverlight 4 beta (and the ability to upgrade as new beta releases come out).
Whether that is a virtual machine or a real machine, it is obviously a requirement that should be considered before volunteering, as it requires time and maybe money to get that going.
I can’t manage a lot of people, but some help is needed – especially in areas where I know I won’t have time to pay attention (Windows Forms may be the most notable, and also the idea of an installer, VS templates – that whole area).
As you might remember I have changes to CslaActionExtender to propose. I've done some work (custom changes to Csla) around 3 areas: validation common rules (NoDuplicates), Windows Forms and Remoting (TCP channel). This aren't key areas of the framework and some of the features I'm planning can be done in satelite assemblies.
What are you thinking about when you mention Windows Forms?
RockfordLhotka: Similarly, there are some coding standards to follow – the goal with team coding (in my mind) is that it should be impossible to look at a piece of code and tell who wrote it. Everyone on a team should code using exactly the same style. That’s a hard one, but important.
When I talk about Windows Forms, there are a number of items in
the backlog (wish list) dealing with Windows Forms – some with
CslaActionExtender, and some other areas as well.
I don’t intend to spend time myself working on Windows Forms
improvements – my only real concern is maintaining at least the current level
of functionality. But I’m entirely happy to have a couple motivated people take
on the backlog items around Windows Forms. Since 4.0 moves the Csla.Windows
namespace into its own project/assembly, this should be an easier prospect than
it would otherwise have been.
You mention a TCP data portal channel – the only data portal
channel I expect to leave in core CSLA is the WCF channel. The other three
channels (Remoting, asmx and ES) will move into individual proxyhost projects
(RemotingProxyHost, EnterpriseServicesProxyHost and WebServicesProxyHost). They’ll
still be part of the CSLA .NET project – just in their own assemblies. I’m OK
with other mainstream proxyhost projects being there too – though I think more
esoteric protocols (someone once talked about a channel over IM?) are a little
too silly for my taste :)
I'm going to rekindle this thread. A couple people did express interest a few weeks ago, but things change :)
As you are aware, there's a very early 4.0 preview online. Before accepting help I wanted to get the basic directory structure rearranged. Doing that sort of change while other people are working in the repository makes for nearly impossible merges, so it was best to get it out of the way first.
But that's done, and now that the folders and projects are in place it is possible to work on specific tasks.
To help, you MUST have a Visual Studio 2010 Beta 2 machine (real or virtual). You must be able to install TortoiseSvn. You must be able to conform to the basic coding style used in the CSLA codebase. You must be good at C# and have a solid understanding of CSLA .NET. Finally, you must sign a contributor agreement providing legal protections to you and me, and clearly defining that Marimer LLC (my company) owns all code and other assets (images, etc) contributed to the effort.
If you are interested, please send email to rocky at lhotka.net.
Copyright (c) Marimer LLC