Future direction

Topics: Web Client Software Factory
Oct 26, 2006 at 10:37 AM
Firstly I'd like to say 'keep up the good work.' The wcsf seems to be coming along nicely.

However, I have a couple of questions regarding the future direction:

The cab is separated between the base library and the winforms library. Are there any plans to bring the new cwab into this architecture? (Allowing, of course, for the fact that web applications are not windonws applications)

I am missing features comparable to the cab's UiExtensions and Workspaces machanisms. Are there any plans to provide comparable functionality? Will it be possible to use any server control (ie. UserControl derivatives) as a view implementation, along the lines of cab's SmartParts?

I look forward to any answers.

Oct 26, 2006 at 6:20 PM
Hi Darius,

Thanks for the feedback. Can you clarify what you mean by the separation between the base library and WinForms? Or, better yet, what you hope to see from a development standpoint. With CAB, it was certainly a goal to allow the composable architecture to be applicable for WinForms or WPF. Are you looking for an architecture that would apply the same way in ASP.NET 2.0, and also be extensible to another Web presentation framework? Or perphas you means something else altogether.

Regarding UI extension sites and user controls, our first priority has been to ensure composability at the page level. That is, modules can easily plug pages into the Web site. We are also attempting to flush out requirements around composability within a page. In that respect, can you provide some sceanarios where you would see this as beneficial?

Oct 27, 2006 at 8:07 PM
Hi Tim,

What I mean with the separation in cab is the two assemblies/project CompositeUI and CompositeUI.WinForms. I wonder why existing classes such as WorkItem, Controller, etc. are being reinvented for the cwab instead of creating a CompositeUI.WebForms for example.

It is obvious that the needs of a web application differ from those of a smartclient/windows application. However, I am sure there is enough in common to factor out a commmon set of classes, strategies, services, etc.

I am not directly interested in another web presentation framework, but am waiting to see what you have to say about Atlas (asp.Net 2.0 Ajax). You state on the main project page that atlas will be considered, but I don't think I've seen anything yet!

As to UIExtensions and work spaces: I a involved in a couple of projects for customers who want web applications which work in a very similar fashion to windows applications. That is, consist of a series of modules which run in a shell containing a menu bar, toolbar and status bar. Depending on which modules are available, items should be added to these structures. Selecting toolbar or menu items results on information being displayed to the user and optionally being updateable.

My current framework is based on asp.Net 2.0 and atlas. Custom UserControls are loaded within an UpdatePanel depending on which menu item was clicked. Data is available in a central place from where the activated controls can reach it.

As I'm sure you can see, this is somewhat different from the scenarios which are currently supported by the cwab: I have only one aspx page of interest and user interaction does not lead to navigating to different pages, but loading different views into a 'WorkSpace'. Also, different modules, possibly configured in after deployment, should be able to add UIElements (menu items, etc.) to the main 'shell'.

So, what I'd really like to learn, is whether I can expect something in this direction at some stage, or if my needs are special and not of interest to the team and wider community, in which case I shall continue to develope my framework in its own direction.

Many thanks,
Oct 29, 2006 at 8:25 PM
Hi - the requirements you describe are very well in line with 'composite web' scenarios.

I'd like to make a couple of comments:
- re: naming of workitems etc. We happened to take the desktop CAB names as part of our first implementation. Especially 'workitem' we discussed renaming since the 'workitems' in CWAB are not akin in usage scenario to those in CAB.

UI Elements: Again, we haven't brought in a genericized implmentation but there is something akin in the way sitemap nodes are registered. Some folks see sitemap nodes and think 'ui elements' because they may be displayed in a menu, others think sitemap nodes are just info about the site, that happens to be displayed by such a menu.

Workspaces (which are related to what you describe with the update panel) - again, we haven't done much UI-level composition. But I would encourage you to try to take an approach in your code where views aren't too coupled to the visual 'container' they will be shon into - the example you mention IMO works fine. in terms of scope I'm not sure we will hit that scenario for at least the next month.

Here's what you can do to help us:
- what are the features of desktop CAB that YOU would like to see in the CWAB? Eg comands, event broker
- what are the new/different requirements specific to web that would help you build these apps?
- Can you write snips of code to explain what you would want your app code to look like when 'showing' views in a standard 'shell'? E.g. aWorkspace.Views.Add(myView) and then you expect that view to be rendered every time the workspace control gets rendered...dunno. Tell us what you'd like to see, I can't promise we'll get to everything but it will influence our priority discussions. Thanks!
Nov 15, 2006 at 9:36 AM
I'm totaly with Darius on this.

Some foundation modules are UI independent but can be context dependent.

In WinCAB, that context can be provided by the WorkItem and services published in it.

It would be great to have some modules that are binary compatible between WinCAB and WebCAB or, at least, source compatible. Having the same WorkItem (source-wise, at least) would enable that.

I'm talking about modulos that provide access to backend services like authorization, authentication, business model, etc.

And it would be nice to be able to reuse presenters across WinCAB and WebCAB.
Nov 15, 2006 at 4:44 PM
I completely third this concept of code-reuse.
My original "interpretation" of this project was that it would be a new "front-end" set of code that would connect to a set of WorkItems or business layer code that might have been written as part of a WinForms app. This software factory would then be run in conjunction with CAB or a version of CAB enabling multiple GUIs on the same back-end set of code.

I don't want to discredit all of the work that's been done (and I really enjoy the framework) but I think it's something that should seriously be considered in the future. My current problem: I have to have 2 completely different middle tiers for the same application - web and win. I understand that maybe there were some shortcomingings in the CAB environment as it related to the web - I would have assumed though that CAB would have been extended or revised - not scrapped.

Nov 15, 2006 at 5:25 PM
I do not forth you entirely.

I don't think that you can reuse UI in order to build a good UI to Web and Windows. I don’t think you can even reuse across Web UI and mobile Web UI.

But, if I want to plug in my authorization service or any other foundational service by registering a module, it should not have any dependencies on WinCAB or WebCAB if it doesn’t need to, even if it means changing WinCAB in the near future.

Using RootContainer instead of RootWorkItem unnecessarily breaks usage across environments.