Just got a mail about a new version of the plugin.
This update features:
* Full compatibility with Aptana Studio 1.2
* Support for path/folder information in design element names
* Support for local databases
* Support for drag & drop copying to and from the file system
* Fixed last byte truncation bug affecting certain file resource lengths
* Improved performance retrieving design elements from large databases
For a complete list of changes in this release:
http://code.google.com/p/domino-aptana/issues/list?can=1&q=milestone:Release0.6
To install or upgrade to this version, point your Eclipse/Aptanaupdate manager to:
http://www.jeffgilfelt.com/eclipseplugins/
For further information and complete installation instructions:
http://www.jeffgilfelt.com/DominoAptana/
To participate in the project or to access the source code:
http://code.google.com/p/domino-aptana/
I know I'm downloading it. If you work with CSS and/or Javascript-files for Notes/Domino applications, I recommend that you try it out.
Monday, October 27, 2008
Tuesday, October 21, 2008
Lotus Domino Designer Wiki - XPages
If you're not already subscribing to the RSS-feed, you should. Plenty of new content is being written at the moment.
The XPages-part
The XPages-part
Friday, October 17, 2008
The new templating engine - Preliminary testing
I decided to do some testing of the engine (currently in alpha-stage). At work, I mainly work on content management.
One of our databases has ~5000 (5321) documents (content and categories). They reside in a CMS-type of application.
The current render-engine (using LS/Forall) in the CMS can't deal with that amount of data, when printing the entire structure. After 55 seconds, the rendering stops with no output. Of course, the old engine isn't perfect, and it wasn't built to deal with that amount of data.
When rendering the same markup, with the engine I'm currently working on, it renders in 2.3 seconds, with maximum data being processed in Evaluate (the more data formula can process in a run, the faster it runs). The resulting HTML weighs in at 704KB.
Both tests were done on my 2GHz/2GB RAM laptop.
I thought it would be fast, but this is way better than I expected..
If IBM upped the amount of data formula/evaluate could handle, the engine could probably render the structure in just above one second.
Update: Did a little testing in N8.5/XPages (same markup as in the above tests). As other bloggers has mentioned, XPages are fast. What I really don't like about the current version in Beta2 is that you can't control if Dojo is loaded with the page. As far as I know, there is no way to make a regular webpage without client-side JS (Dojo). I hope they fix that in the final version.
Hopefully they implement some kind of dependency-system. It loads what it needs for the widgets you use, then you can decide on the rest yourself (using checkboxes/etc).
One of our databases has ~5000 (5321) documents (content and categories). They reside in a CMS-type of application.
The current render-engine (using LS/Forall) in the CMS can't deal with that amount of data, when printing the entire structure. After 55 seconds, the rendering stops with no output. Of course, the old engine isn't perfect, and it wasn't built to deal with that amount of data.
When rendering the same markup, with the engine I'm currently working on, it renders in 2.3 seconds, with maximum data being processed in Evaluate (the more data formula can process in a run, the faster it runs). The resulting HTML weighs in at 704KB.
Both tests were done on my 2GHz/2GB RAM laptop.
I thought it would be fast, but this is way better than I expected..
If IBM upped the amount of data formula/evaluate could handle, the engine could probably render the structure in just above one second.
Update: Did a little testing in N8.5/XPages (same markup as in the above tests). As other bloggers has mentioned, XPages are fast. What I really don't like about the current version in Beta2 is that you can't control if Dojo is loaded with the page. As far as I know, there is no way to make a regular webpage without client-side JS (Dojo). I hope they fix that in the final version.
Hopefully they implement some kind of dependency-system. It loads what it needs for the widgets you use, then you can decide on the rest yourself (using checkboxes/etc).
Wednesday, October 15, 2008
High performance readable conditional templates
My search for the perfect templating solution for webapps seems to be neverending.
In my latest concoction, I feel I've got a decent mix between readability, speed and flexibility.
It started out with my feeling that using "readable lookup columns" was a bit to verbose/data-heavy for templating.
I like pipe-separated column values, but on their own, in a template, they can be hard to read.
E.g.
What I want to write is something like this:
In the demoapp I'm currently working on, I pick the field-labels (e.g. $name) from the first line in the lookup-column (fields := ...) using the Formula-property of NotesColumn.
This way, I don't have to maintain documentation of the indexes of the different values, nor the position of the values.
To get the most performance out of the rendering-engine, one more or less has to use evaluated formula-code. Iterating over an array of column-values using Forall/Replace is slower. It's more and more noticable the more documents/values one is putting through the rendering engine. If it's slow with one user, it's going to get a lot slower with hundred users/etc.
If all you were rendering were static content, and have a decent caching-engine, performance per render would be less of a problem.
My current solution is to join the array of column-values to a formula-interpretable-list. Due to Evaluate's limit on length of returned data, I have to process the data in snippets.
E.g. LS-array:
All the templates are "compiled" to @ReplaceSubstring. You can see how I compile/process the templates and data when the demoapp is complete.
Another downside to using pure LS-processing of templates is that it's hard to do conditional templating without slowing down the rendering-engine/writing a lot of code.
Since all data are being processed by Evaluate/Formula, it's quite easy to add conditional compiling as well (@If condition -> conditionalTemplate ). If you want, you can use one template for all the data, or you can have multiple conditions, and a default template.
Example-code from an agent printing a table from 499 documents
Result - odd/even-template
Result - mixed conditional template
At the bottom of the above HTML-files, you can see the amount of values/rendering-time. The time includes all processing, getting field-indexes, columnvalues, rendering, etc. The processing is done on localhost, on my laptop (Core 2 Duo 2GHz/2GB RAM) in Windows XP.
I'm not done yet with the implementation. The current engine is comprised of two classes. One that renders arrays of pipe-separated values (could also process CSV-files), and a subclass that processes the columnvalues of a view.
I plan to add another subclass to the first. This would let you use ft-search on a view, and sort the resulting columnvalues on a field/value in the resulting columnvalues.
If you have further suggestions/wishes/are curious about the code, contact me. Preferably throught comments. :)
I can't say when the demoapp is complete. I'll probably have another update or two before the app is ready for the masses.
In my latest concoction, I feel I've got a decent mix between readability, speed and flexibility.
Readability
It started out with my feeling that using "readable lookup columns" was a bit to verbose/data-heavy for templating.
I like pipe-separated column values, but on their own, in a template, they can be hard to read.
E.g.
template = "<tr><td>$1</td><td>$2</td></tr>"
What I want to write is something like this:
template = "<tr><td>$name</td><td>$address</td></tr>"
In the demoapp I'm currently working on, I pick the field-labels (e.g. $name) from the first line in the lookup-column (fields := ...) using the Formula-property of NotesColumn.
fields := "firstName" : "lastName" : "company" : "address";
@Implode( @Transform( fields ; "fieldname" ;
@Text( @GetField( fieldname ) ) ) ; "|" )
This way, I don't have to maintain documentation of the indexes of the different values, nor the position of the values.
Performance
To get the most performance out of the rendering-engine, one more or less has to use evaluated formula-code. Iterating over an array of column-values using Forall/Replace is slower. It's more and more noticable the more documents/values one is putting through the rendering engine. If it's slow with one user, it's going to get a lot slower with hundred users/etc.
If all you were rendering were static content, and have a decent caching-engine, performance per render would be less of a problem.
My current solution is to join the array of column-values to a formula-interpretable-list. Due to Evaluate's limit on length of returned data, I have to process the data in snippets.
E.g. LS-array:
array = ["Party","Hard"] '(brackets to indicate an array)
formulaListString = |"| + Join( array, |":"| ) + |"|
'result: "Party":"Hard"
All the templates are "compiled" to @ReplaceSubstring. You can see how I compile/process the templates and data when the demoapp is complete.
Flexibility
Another downside to using pure LS-processing of templates is that it's hard to do conditional templating without slowing down the rendering-engine/writing a lot of code.
Since all data are being processed by Evaluate/Formula, it's quite easy to add conditional compiling as well (@If condition -> conditionalTemplate ). If you want, you can use one template for all the data, or you can have multiple conditions, and a default template.
Example-code/results
Example-code from an agent printing a table from 499 documents
Result - odd/even-template
Result - mixed conditional template
At the bottom of the above HTML-files, you can see the amount of values/rendering-time. The time includes all processing, getting field-indexes, columnvalues, rendering, etc. The processing is done on localhost, on my laptop (Core 2 Duo 2GHz/2GB RAM) in Windows XP.
I'm not done yet with the implementation. The current engine is comprised of two classes. One that renders arrays of pipe-separated values (could also process CSV-files), and a subclass that processes the columnvalues of a view.
I plan to add another subclass to the first. This would let you use ft-search on a view, and sort the resulting columnvalues on a field/value in the resulting columnvalues.
If you have further suggestions/wishes/are curious about the code, contact me. Preferably throught comments. :)
I can't say when the demoapp is complete. I'll probably have another update or two before the app is ready for the masses.
Friday, October 10, 2008
Domino Developer Plugin for Aptana Studio
In my previous post, I mentioned that I'd like to see Aptana in DDE. Well.. It seems that we're not far away. Nick commented that there is a project named Domino Developer Plugin for Aptana Studio. Aptana is quantum leaps better the integrated JS-editor in Domino. You get code complete for Js, DOM and JS-frameworks, etc.
I've only tested it for fifteen minutes or so, but so far it seems excellent. One of my applications is more or less pure JS/CSS. Not having to deal with Domino Designer (Open/Refresh) is excellent. When you save, the change goes directly to the NSF.
I had a little trouble with it at first. I added the Notes path to the PATH environment variable. But I got an error message whatever I did.
I restarted the computer, and now it works fine. If you get this error message, "java.lang.UnsatisfiedLinkError: no nlsxbe in java.library.path" after setting PATH, then you probably need to restart your computer.
Highly recommended!
(Unless there are some horrid bugs I'm not aware of)
Update: It seems Jeff Gilfelt, the author of the "Domino Developer Plugin for Aptana Studio" might be getting some competition from an IBM employee, Niklas Hedloff. He's working on a plugin that goes one step further than Jeff's. It allows you to import Javascript frameworks to NSF's directly from within Aptana, using drag'n drop. Read more about it in his article, "Lotus Notes plugin for Aptana Studio".
The future for Domino web developers looks promising, even if your company isn't of the first to adopt Notes/Domino 8.5 and XPages. :)
Update 2: I've found one re-creatable bug in the current version. When saving a file-resource, the last character is cut. I've reported the error to Jeff. Hopefully he can get a fix out in the nearest future.
I've only tested it for fifteen minutes or so, but so far it seems excellent. One of my applications is more or less pure JS/CSS. Not having to deal with Domino Designer (Open/Refresh) is excellent. When you save, the change goes directly to the NSF.
I had a little trouble with it at first. I added the Notes path to the PATH environment variable. But I got an error message whatever I did.
I restarted the computer, and now it works fine. If you get this error message, "java.lang.UnsatisfiedLinkError: no nlsxbe in java.library.path" after setting PATH, then you probably need to restart your computer.
Highly recommended!
(Unless there are some horrid bugs I'm not aware of)
Update: It seems Jeff Gilfelt, the author of the "Domino Developer Plugin for Aptana Studio" might be getting some competition from an IBM employee, Niklas Hedloff. He's working on a plugin that goes one step further than Jeff's. It allows you to import Javascript frameworks to NSF's directly from within Aptana, using drag'n drop. Read more about it in his article, "Lotus Notes plugin for Aptana Studio".
The future for Domino web developers looks promising, even if your company isn't of the first to adopt Notes/Domino 8.5 and XPages. :)
Update 2: I've found one re-creatable bug in the current version. When saving a file-resource, the last character is cut. I've reported the error to Jeff. Hopefully he can get a fix out in the nearest future.
Thursday, October 9, 2008
ArrayAppend accepts single values
From the documentation, it looks like you need two arrays to use ArrayAppend. In Notes 8.02, at least, you can also use this function to add single values at the end of a dynamic array (arrays created using Split, NotesItemValues, etc).
Update: To do the equivalent of Array.unshift in Javascript (add a value to the start of an array), it seems you need to split the value (the first parameter has to be an array).
I would think there would be a performance hit when dealing with a lot of values, but at least it's possible.
If IBM would just give us the Eclipse Java editor inside DDE, I could finally stop dealing with the crappy array-implementation in LS.
What would be even better was if IBM teamed up with Aptana for editing server-side Javascript agents/script libraries.. Throw in E4X for dealing with XML.. One can always dream.. :D
Dim i As Integer, numberlist As Variant
numberList = Split( 1 )
For i = 2 To 20
numberList = Arrayappend( numberlist, i )
Next
Print Join( numberList, ", " )
'Prints 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20
Update: To do the equivalent of Array.unshift in Javascript (add a value to the start of an array), it seems you need to split the value (the first parameter has to be an array).
Dim arr As Variant, i As Integer
arr = Split( 20 )
i = 20
While i > 0
i = i - 1
arr = Arrayappend( Split( i ), arr )
Wend
Print Join( arr, ", " )
'Prints 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20
I would think there would be a performance hit when dealing with a lot of values, but at least it's possible.
If IBM would just give us the Eclipse Java editor inside DDE, I could finally stop dealing with the crappy array-implementation in LS.
What would be even better was if IBM teamed up with Aptana for editing server-side Javascript agents/script libraries.. Throw in E4X for dealing with XML.. One can always dream.. :D