My Domino Designer 9.0 Wish List
Category General
1) Pixels as measurement unit
Add "Pixels" as an additional measurement unit for margins, table sizes and wherever possible.This would make it easier to exactly postion tables and texts.
2) Dockable tables
Make tables "dockable".This means that they can be placed "on top" of each without even one pixel between them.
3) Could we get a debugger for Java ?
Most developers are used to Lotus-Script. They would not have much of a problem to write scripts in Java. The general syntax can be learned in a few hours and the main knowledge lies actually in the object-modell of the Notes-Classes, which are identical to LotusScript. However what we are missing is a step-by-step code debugger like the one for LotusScript. Once we get this you will see immedialtely a increased usage of Java in LN.
4) Computed View-Column-Titles
Right now you have to use „fixed“ text values in column titles. This makes it difficult to design multi-language applications as it is not acceptable to create several copies of a view only to get proper titles on it. Everywere else (forms,outlines,... )we can easily compute texts so why not here.
1) Pixels as measurement unit
Add "Pixels" as an additional measurement unit for margins, table sizes and wherever possible.This would make it easier to exactly postion tables and texts.
2) Dockable tables
Make tables "dockable".This means that they can be placed "on top" of each without even one pixel between them.
3) Could we get a debugger for Java ?
Most developers are used to Lotus-Script. They would not have much of a problem to write scripts in Java. The general syntax can be learned in a few hours and the main knowledge lies actually in the object-modell of the Notes-Classes, which are identical to LotusScript. However what we are missing is a step-by-step code debugger like the one for LotusScript. Once we get this you will see immedialtely a increased usage of Java in LN.
4) Computed View-Column-Titles
Right now you have to use „fixed“ text values in column titles. This makes it difficult to design multi-language applications as it is not acceptable to create several copies of a view only to get proper titles on it. Everywere else (forms,outlines,... )we can easily compute texts so why not here.
5) Some good solution for keywords with aliases in views
Keywords are a standard in an application and it would make totaly sense to use the available alias ("xxx | 1") functionality.
However if you want to use this keywords in views (which is very often the case as categories) then aliases are now totally useless.
Why should i store my data in a document in a nice way (as an alias), if i have to hardcode the text values into every view where i want to display them ?
We need a solution where a view-column formula can read the text values for aliases for example from a profile-documen
(Oh and this is even more important for multi language applications as well.)
6) One "perfect" solution to display only a (dynamical) subset of data from a view
Right now we have "Embedded views with show single category","Private views", "@ViewSetInfo", "DB2 Query view",
All of these solutions do nearly the same thing: Presenting the user only a dynamically filtered part of a view.
None of these solutions works perfect.
A) Embedded View with “show single category”
With this we can do very nice things but:
- "Collapse All" - makes that all data "disappears", because also the "hidden" category has been collapsed
- The view itself has to be saved with a "Expand All”-status, otherwise no data is displayed. If you have several categories you can not achieve it that only the first is expanded but the others are collapsed. Ahhh
- Ctrl-A - selects ALL in the wholes view. Even the ones, whcih the user cant see. If he now triggers an action on selected docs this can lead to a catastrophe
- If you put an “Embedded View” into a blank page/form and set its height ans width to 100% then you still get one empty line above the view which is visible.(Hide-whens won't help)
This makes it "ugly" to display such a view directly from the ouline.
- Does not work in calendar views
- Resortable columns do not work
B) Private (on first use ) Views
Actually even this is a solution for the same problem, only that the "filter" is limited by the actual username of the current user. And if you add the other problems like "index size", "design-updates", "strange errors" then this solution is not acceptable as well.
C) @ViewSet Info
Again a nice try but:
- the filter has to be cleared one you leave the view or else it will filter all other views where you switch to
- the categories have to be expanded for the filter to work
- Ctrl-A selects still too many document
- it does not work with flat views at all
- it acts "weird" sometimes (yes i know this is not really technical, but it is true)
D) With DB2 as a backend we now get an other option which is "Query view"
I have not worked with this yet, but my tests seemed that this is no "perfect" solution as well.
- they work only on a server and never locally
- the performance is low because there is no prepared view index
- there is a limit displayed documents (which can be changen via notes.ini, but the limit is still there)
I would suggest you focus on one solution and make it really perfect so that expands/collapse, select-all, column resorts, column totals all simply work the same way wheter i have a "full view" or a "filtered view".
7) Start an agent in a background thread from LotusScript
Well for some time we can start agents on the clients in a "background-thread". This is set up in the agent properties itself.
However it works only if this agent it triggers with @Command([ToolsRunMacro]). If it is triggered via LotusScript it does not run in the background thread.
This is necessary because only this way we can pass some values to the agent in an "easy" way.
8) Replica-ID format
Please make @-Functions and LotusScript both use any format of the Replica-ID (with or without the „:“). (Ok its not important really, but why not make our lives easier )
9) Provide us with a XSL-Stylesheet to completly display exported DXL-content of Rich-Text-Fields
Well with DXL it is now very easy to export any richtext out of LN. But to display it properly in HTML is a pain.
Why do we all have to write our own primitive XSL-Stylesheets if it could be done once and perfect ?



Comments
lars, 03.23.2007 00:48:53 | - Website - |
With Lotusscript, theres nothing to install and I've got a debugger that is "just there", I keep hearing promises of Eclipse this and Eclipse that, but, I've heard them for years and still never seen it with my eyes. I've read the "how to install eclipse in 7 days" manual, but, never completed it.
Java is just not ready yet. IBM just does not seem to get it.
Dwight Wilbanks, 03.30.2007 17:52:13 | - Website - |
Hinshaw, 12.02.2010 10:38:08 | - Website - |
Potter, 12.13.2010 04:22:36 | - Website - |
nickel color metal bottle opener review, 10.01.2011 09:25:37 | - Website - |
8 foot closet doors, 10.07.2011 09:24:24 | - Website - |
coafuri 2012 par lung, 10.12.2011 10:01:11 | - Website - |
wedding photo thank you cards 2012, 10.17.2011 17:04:31 | - Website - |