• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (14)

1 localhost commented Permalink

Q. Will third party tool developers have access to the designer views and editors etc. via extension points?

A. (hint: Yes!) ?
Will we some of the Jazz collaboratvie development research project ideas impemented in DD/Eclipse?
A. (hint: Yes!) ?

2 localhost commented Permalink

Come on !! GO a step forward !! Rewrite it on Java !!!

If you are NOT going to re-qrite it on Java, just, do´nt do anything.... it would only add more confussion to the community..

3 localhost commented Permalink

There's no need to rewrite the whole thing - there's lots of good stuff that works fine, and what language it's written in really doesn't matter.

What we will do is to replace the pieces that will improve the experience for our developers - to use the Eclipse script editors instead of the current script editor, etc!

4 localhost commented Permalink

Some questions: Are you going to support some refactorings? If yes, which? What about subversion or cvs integration? Any thoughts about those?

thank you

5 localhost commented Permalink

As I understand it the Domino Designer for Eclipse is a Windows only binary. Wouldn't it make sense to have also a binary for mac or linux?

6 localhost commented Trackback

This is great. It shows us a path for Domino Designer that will allow it to grow in the future, and not just be something that is "maintained".

I would hope that Dom. Designer gets better and better at designing HTML/CSS (and Hannover at rendering it), as this will bring the platforms together over time. Right now, the default look at feel for Domino is "so last century", so it also involves the server having better default appearances, etc.
My #1 wish with for HTML/CSS is that Hannover be able to refresh HTML through uidoc (which is not possible right now). Then we can get really funky with UI constructs within Hannover (and even get people more and more comfortable with designing in HTML/CSS).
My #1 wish for Domino is far better HTML/CSS defaults and extensibility (yes, that includes far better view & table design/rendering in Hannover).
#1 for Domino Designer is to know that there is a future in it...and for this you just gave us some great hope for the future.
Thank you for posting.

7 localhost commented Permalink

What i want mare than anything is a view template to apply to all views of a database, that includes the action bar and rows and alterante row colors. It is a real pain to update 50 views and action bars when ou want to chnge the look and feel of a database.

8 localhost commented Permalink

Would it be correct to say that all this does is take the existing Domino Designer and surface it in Eclipse? If that is the case then what's the big deal? Sure it shows a future direction, but that doesn't impress me much. I suppose for the people who work with Workplace Designer and RAD it would make things a little easier. I'm not one of those so this is of little benefit to me.

9 localhost commented Permalink

Maureen, I don't use Eclipse so I'm not sure what I'm supposed to be imagining. =) Believe it or not there are a lot of people who have no reason to use Eclipse.

10 localhost commented Permalink

That sounds like a great step in the right direction! Could you give any more details on what you mean by "opening up the development platform"? Is this something intrinsic with Domino Designer moving to Eclipse, or is it something else?

11 localhost commented Permalink

"Opening up the development platform" means it will be easier to add features to Dom. Des. in the future once we are on this path.


12 localhost commented Permalink

Like @1 and others above, I was/am hoping that "opening up the development platform" would mean "there will be extension points to let 3rd party tools use parts of the functionality" - the editors for the various scripting languages would be a great start.

13 localhost commented Permalink

there will still be work to do for source control management (expressing a design element in a form that a source control system can store without losing anything like signatures). But it means that instead of having to solve that AND put support in the tool framework, we only have to code up the package it as a single entity piece.

Plugins could certainly be added to do anything - but the key to two-way interaction will be to have Domino Designer pieces listen and respond to that. Lots of work to do, but a very exciting path.

14 localhost commented Permalink

Also, to answer Ian's second question re: Hannover - yes, you will be able to extend Hannover using the plugin extension model, as well as the composite application model. (Ditto, for Workplace Designer as we move to plain old Eclipse 3.2.)


Add a Comment Add a Comment