XUL,Formsrenderer,design document?

Topics: General
Feb 6, 2011 at 9:21 AM

HI, I have a couple of questions:

1.I've noticed that developpers used XUL to create console UI.
Isn't too risky to use this proprietary language  knowing that it's not supported by many  browsers?
Aren't there some other alternatives that do same job good enough and have better cross-browser functionality(like jquery UI lib or something).

2.Is FormsRenderer open source or not?It definetly lacks some features like prepopulation by some entity,properties visibility for entity,options dropdown list  filtering ,read-onliness(by entity of by property,event hooks etc ..
It would be nice to have source for it.Is it possible?

3.It's clear that system is well designed but rather high level of abstraction demands time to become famyliar with.
Shall it not be helpful to create some kind of document with high level overview of design and architecture of Composite?
It could describe possible extension points and best practices to developpers who want to contribute as well as some critical DON'T.
It is very important to know vision of the core team on how they see core system being extended by contributors.
Time spent for creation of such a document by core team developper will be compensated by faster initiation  of the developpers new to C1 .

greetings
misha bond

Coordinator
Feb 10, 2011 at 7:25 AM

Hi Misha,

1: The markup that make up the C1 Console is indeed very XUL like, but it isn't 'real XUL' - we made it up to fit our needs for elements like tabs, drop downs, splitters, toolbars etc. (for those interested you can see the markup by viewing the source op .../Composite/top.aspx and if you run the C1 Console on the source code version in dev mode you can right click tabs and view source). XUL is a Mozilla specific tech, but the C1 Console run in both IE and Firefox (and Chrome from 2.1). The reason we didn't grab some of the shelves library like jquery is because those libraries do a lot more than what we need and very little of what we actually need - also we wanted to own the UI. Since the very simple markup parse through js we are able to have both flat files and generated pages on the server side pages that create UI declarative, and at the same time work with the UI via an API on the browser side. Having this layer also made it possible to 'skin' the C1 Console so it looks like a Mac app on Macs, have olive tabs when running on XP with Olive theme etc.

2: We are looking into creating a 'HQ TFS to CodePlex' job for packages - stay tuned.

3: We don't have a "Composite C1 - The Architecture" article, but rather some more task oriented articles on our documentation website. I myself have tried simplifying Composite C1 into a diagram, but failed miserably every time probably due to a lack of communicative skills. If you have some good examples of people who have done this right feel free to post some inspiration. If I could write up an article that give the reader a complete overview of the architecture of Composite C1 I would love to do so. Anyway, take a peak in ~/App_Data/Composite/Composite.config for an overview of the providers we support.

Marcus

 

 

 

Feb 10, 2011 at 7:57 AM

1.Nice
2.Let me know,then,please.
3.Commenting code as you know is already kind of documentation.Tools like Doxygen (open source) kan generate then docs in couple of minutes  as well as do some
limited diagramming .I've  used it to generate docs for Composite and find it rather useful in the form of website.You cand do it for latest releases on your website and
I believe it can lock more developeers to your website.

3i. as far as I know you through your answers ,you're definetly good in communication.Lack of time   looks more plausible;) I have this problem as well.