I've also been told on several occasions (conversations in the LS labs) that there *were* licensing issues around Rhino but I don't think that those apply to the the version of Rhino that ships with Java 6.

While we're at it, let's have E4X too. It's an optional Ecma spec that adds XML literal and object syntax to javascript. It's been in Javascript since 1.6.

Javascript 1.8.2 is in your Firefox and it implements some of Ecmascript 5.

Form lab conversations, the Xpages team is well aware of all this and would like to implement but...yada yada yada

Wasn't the XPages Javascript implementation was acquired?

And speaking of SSJS, I's like to see the CommonJS stuff implemented too. That's where the real server-side action is in the JS world. Every other Javascript engine implementation is moving in this direction.

{ Link }

Yes!!!, and while they are at it, why not implement Ecmascript 5, the current spec as of last December. Just because IBM voted against Ecmascript 5 doesn't mean they can't implement it.

If they use the current version of Rhino, we would get the added benefit of all the features in Javascript 1.7. They could at least use the version of Rhino that ships with Java 6.x as the JSR 223 refence implementation. I think that's Javascript 1.5 +- a few things. Still more language features than Ecmascript 1.3.

If they don't keep up with the ECMA spec, we'll have an old non-standard scripting language in Notes. Again. The Ecmascript 1.3 spec is 10 years old.

The existing Eclipse refactoring capabilities can be used to the extent that the AST is available to the refactoring APIs. A parse tree from the editor isn't going to cut it. Refactoring requires deep semantic knowledge of the code.

If IBM is producing a Lotusscript parser->AST in Java, well then...let the community have at it.

This is important. IBM, please vote "Aye" on the Ecmascript 5 standard next month. Word on the street is that you may not (#jsconf) . And please implement the new standard in your Ecmascript engine. E4X would be really nice too.

Don't Lotusscript the Javascript.

That's one code base I never want to touch.

Stayed at an outlying hotel in '96. It sucked. The bus schedule felt like a curfew. Good idea.

Type inferencing would be nice. Scala does this on the JVM.

Yes! We usually have the agents "call home" so we know they're alive and can track progress but someone else working at the console can't see them and they bounce amgr....#$%^!!

Great idea. Perhaps a URI format that could specify replica IDs and/or Notespaths/filepaths.

I'm now convinced that this is a tool and/or process issue. Changing my vote.

@18 - the trend is not specific to the type system...more compile-time options are being added. This was a close one for me. Most of the Notes DB Admin stuff I do is in python with extended syntax, operator overloading and string literals:

doc.someitem + = ['three','more','values']

Maybe the extended syntax check could be an tool option. Check it before the compiler (along with other code checks - see Buchan's recent post on tools). That way the Option wouldn't move around with the code.

The trend in scripting languages is toward optional type declaration (Ecmascript 4 and the javascript engine in XPages). Option ExtendedSyntax would be consistent with that direction. While there could be some pain as is Ben's scenario, it nets out as a plus for me.

{ Link }

There's a few times I would like to have had "Send it Yesterday" ;-)

I like the idea of surfacing this as a feature. In my experience, the standard doc level ACL has caused all kinds of problems, even if it is occasionally a good solution for something.

Promoting because I can't think of a better idea and what they've done up until now doesn't work.

Designer on Eclipse will make this easier. The resource model of the IDE allows for code to come from anywhere. If VCS integration is not on the roadmap, this is a good opportunity. I agree that transparency is important, working a VCS is not a requirement.

CIAO (which I use everyday at my day job) is just now getting branching and merging. We'd all benefit from a little competition.

We've been hearing for years how it would be too slow to do all kinds of things in the view renderer. I say let me shoot myself in the foot.

Good idea..using Alt+E+D on selected documents is scary. I'm just know it's gonna delete 'em some day.

I'd like to see a schema enforced unk table. Go ahead and use the items defined in the schema (data dictionary) in any design elements you like but you can't add new items to the db until they're in the schema. It doesn't changes the flat namespace of Notes, just constrains it. See "controlled vocabulary":

{ Link }

Another option would to report any new items added to the db so that the db owner/designer could know Joe Smith added those items on 12-18-2007 10:00AM. It would also be enforced at compile time in Designer.

Auditors, schema-free dbs and legacy applications are the stuff of nightmares. Of course, none of *us* would ever play fast and loose with Notes data ;-)

@4 - It is a new world..but that world does not require the java langauge to participate. It just requires that our language run on the jvm. I don't expect lotusscript or @f() to go there, but javascript is already there. It's been there for years with Rhino and the js engine in Workplace Designer and most Notes/Domino developer know it well enough.

Making Expeditor and Eclipse APIs available to more developers is good for the platform. It's even good for us java developers. We can move forward at a higher velocity and "drop down" to java as required. Most people will be happy to build UI components in javascript (or perhaps other jvm hosted scripting languages) and may never have to become proficient in java. Java just simply isn't *required* for many things that most developers need to do. For the lack of integrated, supported alternatives (on the Notes platform), we use it. IBM appears to be solving that problem.

From what I can tell, you'll be able to do this and most other Expeditor and Eclipse UI stuff in javascript in a future version. The javascript engine is the one from Workplace so it runs on the jvm (like Rhino) and already has the Notes back end API. With the UI API, you should be able to build sidebars, poups, wizard and and any other UI components. It also has access to all other java APIs so you'll have network IO from sockets to http and everything else.

I don't know if there are any plans for doing this in Lotusscript. It would almost be easier to port Lotusscript to java and get all that other stuff for free but I won't go there ;-)

If you want to play, promote and name your axe. If you don't want to play, don't vote.

keyboards here.

With Designer moving to the Eclipse platform I would expect to have version control. If not from IBM then from third parties. The abstractions of the Eclipse IDE resource model really help for developing this kind of stuff. I'd like to see SVN and NSF based options from IBM. Git anyone?

oops....A Demote with specific comments has positive value, more value than any single promote.

I agree with Mika. How do you feel when someone tells you that your application is bad, sucks, doesn't work etc. and offers no specifics? A demote without a comment has negative value. It's all noise, no signal. A value with specific comments has positive value, more value than any single promote.

No, it's not ;-)

I don't see how this code is more of a hassle than using the rich text apis. With these methods available, I would consider using the rich text apis to be premature optimization for the example given. The dxl exporter underneath could load lazily once per session. If performance is a real problem, you can always drop down to the other apis. In the mean time, development is faster and there is less code to maintain. The code is also much more readable and less error prone.

I prefer a more declarative approach...'what to do' not 'how to do it'.

I agree that it's easy to write this as a class and several people have done so and published but I find it to be a strange omission compared to every other scripting language I know of. I would expect that this would be an extension of the current array.

A very common use case is to add n items to a list and then iterate over the list, test for membership, extract sublists, apply functions to the items etc...without indexing or keys. I use this far more than indexed arrays or hashmaps/dictionaries in languages that have all three. I'd like to have sets too but that's another post for another day.

Axel. I'm looking for something like JDom for Lotusscript. With that, I would rarely ever need the code and state tracking overhead of SAX. Stax is standard in Java 6.0 now. Also, check out the iterparse function in python:

{ Link }

this and first class functions along with the current ability to create untyped variables would make LS a real dynamic language (modulo metaclasses). Lotusscript could be fun!

I'd like to see tags about yourself or something else more structured than just text for the profile. Linking to other existing profiles would be great but I want to build a view based on profile data (not that those ideas are mutually exclusive). I'm coming from an ISV point of view but I'm sure IBM and others might also want to look for patterns in the noise. If an idea receives a lot of votes both up and down, who votes how could be very valuable. The aggregate tells us something but it's not the whole story.