Two Months, No Articles
I know, I know. Promises, promises. "An article a month for the whole year", he said. Then packs in after seven months.
Well, in my defence, I have been rather busy of late. Please forgive the lack of updates. Free time has been precious over the last two months. The last thing I want to do with this time is write an article. Don't get me wrong, I like doing it, just not when I want to be relaxing. Writing a full length article isn't as easy as you might think. It can take anything from a couple of hours up to a whole day to complete.
Would it make it up to you if I wrote three this month to get us back on target? Not promising this time, but I'll have a go. Got some time alone this weekend so I might try then. If you got ideas for what I should write about let me know. For want of anything better I will start with a follow up (or two) to the last article about rich-text in the browser and talk about advanced settings and customisation.
Would you consider guest articles?
I have one which has been on the cards for a while, entitled "Hacking the Domino Web Server". It has lots of tips and tricks that admins and devlopers should be aware of when designing apps. Especially when it comes to some "undocumented" features.
I would stick it on my "blog" but I've done even less updates than you, and not a lot of people read mine (not that they'd want to anyhow).
If I could send it to you, and let you see what you think.
Always willing to accept guest article Dragon. Send it over.
How about multi role web environments?
We often have a different interface for our staff, managers and clients. I've recently created a database that has 1 group of staff, 2 managers and 9 clients - that's been fun!
I doubt we're alone in that requirement, but there could be some ways to make that easy that are worth writing about.
I'd be happy to share what I've learnt over the last couple of years if it helps.
Hey,
Jake, a few weeks ago, you were thinking about possible solutions to provide comprehensive web logs to users.
Did you find out anything? Any complementary thought about web logs could be interesting (using third party tool, logging in Lotus Script, Domlog extractions, ...)
I had to provide such logs lately, and it would be a pleasure to share what i learnt lately with you.
Best regards,
Luc
Ooh! Ooh! I know one, pick me!
How 'bout an article on xhtml compliant rich text editing. That would make it up ;)
Guys. If you ever have anything worth sharing email it on over!
Paul. I usually use CFD fields in combination with roles. If you have a role called [Admin] then have a CFD called isAdmin. Its formula is simply:
@UserRoles = "[Admin]"
This equates to a Boolean style value which can then be referenced in all other fields and formulas. For example, a Computed Text area could then compute to:
@If(isAdmin; "Welcome Admin"; "Welcome User");
And hide-whens simply refer to the field by name. You can have as many of these fields as there are Roles and place them in all in a common subform, included on all Forms.
Luc. That client ended up settling for a 3rd party analyzer tool that churned through the W3C style logs that the server can export. Not much to it really.
Ferdy. Domino XHTML is an oxymoron ;-)
I´d like to have information about building forms through a database in de Lotus Notes client, without the Designer! Some projects on OpenNTF are working on this, but don´t make any progress. I´d like to have a form generator for my website, so other content managers (without designer) can build forms in Lotus. Building forms in the designer and maintain them is a hell of a job!
Arjan Kessels
I'm with Luc. Even though your client went with the third party option, we all want the ability to not rely on third parties, don't we? Plus, I'm going to have to do something like that soon also. :-) To narrow it down, a discussion of building a function library (in java even) to parse the existing dom log entries for different statistics in a given time frame. Hm. Come to think of it, that sounds boring.
How about you review Echo (mentioned on /. yesterday) and compare it to domino and/or PHP? That would be interesting.
Also wouldn't mind seeing someone pull together a good list of resources of credit card processing... something else I'm going to have to do in a while myself. Using paypal is becoming too kludgy for my liking, even when integrated into a website as we've done (no secrets or innovation there, all you need to know about that is documented on paypals website).
Jerry
Please don't apologize for not keeping up with the articles! Yes, we all love them, but I truly appreciate all the tips you share, even if articles are not every month. Heck, even your comments wind up helping me! Thanks for the tip about using CFD fields with roles you just added. I might have to implement that one soon.
I understand what you mean, however I meant something a little deeper.
I use a profile document (in association with roles) to alter a base CSS for each of the 9 different clients, providing them with a branded site, each client then has as many people with access as required - we have over 50.
I also use a sub form menu with just 5 cfd fields and a view to control navigation through the entire site.
I'll send you a copy of the design if you promise not to laugh! It won't be up to your standard that's for sure :)
How about adding some workflow to this site via the web? Allowing people to submit articles via the web (using the handy-dandy rich text editor), and if approved, get published as a guest article. Of course this creates additional work for Jake as the overall content owner, however if lack of articles is a concern, this may be a venture worth pursuing...Am I off base by suggesting such a feature?
Thanks Debbie.
Paul. With the "isAdmin" field you can do alsorts of stuff. You could do what you mention by pointing to a different CSS resource, based on which role is enabled. It can be as complicated as you need it to be.
Matt. Not off base at all. Quite a good idea. When I get round to the set of mods I've built up I may well make this a feature.
Arjan, I can pretty much guarantee that you are grossly underestimating the effort involved. There is work under way to create a "Designer Lite" (particularly as a web client), but:
1. the user would still need to have a core competency with Notes and Domino;
2. since the user may not be a career Notes/Domino developer, any design elements created (and yes, there always needs to be a corresponding Designer form) need to be verified and validated, then checked, calibrated and run through an x-ray machine before saving;
3. the Notes client is not, and never will be, a good candidate for the "Designer Lite" application because it does not have provisions for anything like positionable widgets (where the web gives us DHTML); and
4. maintaining the forms in Designer yourself is absolutely NOTHING compared to repairing damage to the database (and,perhaps, the server) if anything mentioned above gets broken. You can make a user-configurable form yourself in Designer and let the users "shape" the result with a set-up document. You're not afraid of hide-whens and computed text, are you?
"Designer Lite" makes sense for single-database hosted sites (a "website in a box"; not to be confused with a DelMarva product having the same name) with relatively limited functionality, where users without access to Designer (and with less than Designer access to their database) can configure and assemble the toolkit they're given (probably as part of the standard "blank" template).
If our Jake (or any guest columnist) can find a way to work this into an article, I'd be more than a little bit surprised. The end-user instructions alone would take up several week's postings....
Stan,
I guess this could be done with the following:
a blanket of 10 user-admin-defined fields for each field type (ie, 10 text, 10 plain text, 10 combo, etc.). You could via a profile document turn off/on a field.
a field label system that would allow a user to say "the 5th user defined text field will have the label of 'email address'" etc.
All that, and obviously validation stuff etc is fairly simple to come up with... the problem is now field placement on a particular form...
if there was a WYSIWYG editor that would build the css on-the-fly and allow to you simply apply that CSS to the particular form, then you could (in theory) completely allow a standard end-user to create a form.
I dunno... the markup would be huge, but it's a way that it could be done.
And obviously there's other ways to do it - or should be others - but this is off the top of my head on a Saturday afternoon while watching the kids while my wife is out getting the Chinese food for dinner for us and our visiting family...
well, you get the idea!
-Chris
How about an article about setting up Domino + SSL. I've never really been asked to get this working but can see it happening fairly soon, and on my previous attempts, couldn't get it 100% working. I think I got the domino side and the CA process all sorted but the IE client wouldn't show the 'padlock' icon in the bottom right, which users look for to be sure it's secure. Does the padlock (secure mode) only show when you're using a proper verisgn (or other such) certificate? I thought if you told IE to trust the home-made one, it should?
All of this talk about making forms customizable. I have done something similar. If you follow this link {Link} and click on Spot Quotes and then go back and choose Operational Regions, you will see two similar but different web pages built with the same form. Business users are able to customize these forms and choose who gets the notifications. The other feature that I think is great is that it can also use the HTTP referer to figure out which version of itself to show. So, you can say, "If someone clicks on Contact Us from x page, show this version of the form and send it to John Smith, but if they click on Contact Us from y page, show this other version of the form and send it to Jane."
Similar to Chris' posting above, we have a web based forms database where the fields (and much of the functionality) is defined by a user without the designer (using up to 60 fields) with validation etc, field types (e.g. text,number, date,drop down lists etc).
(By the way the old version was on sandbox, but I can't seem to get a response on the latest submission, so if anyone is interested in a copy, let me know).
Also, you could do it (I believe) with XML.
The idea I had floated essentially uses DHTML in the browser to design forms & views, then builds a corresponding simplified XML design document, which gets submitted to Domino. At the server, the design is verified and, if it passes, it translated to proper DXL. That DXL is then imported by a run-on-server agent to become a genuine user-customised Domino Design Note. The host is protected from user stupidity in the process; the user never needs to have more than Editor access to a hosted database, and the options granted by the Designer Lite client will not allow users to create designs that would choke the server or become a WTF showcase.
Mind you, I've got some work ahead before this is even at the proof-of-concept stage....
Could an XForms XML def <--> DXL be an option to consider. At least that way, you would have a standard on one end.
Great article Jake.
Sorry .. was referring to the one about rich text in the browser :)
XForms would work at a basic level, but you need to keep in mind that a Domino form is not just a form definition, it's also the "CGI script" for the submission. In other words, the Designer Lite would need to do validation, data typing, set access flags, compute secondary and tertiary values, invoke safety-checked user agents, etc.
Jono and SSL - that would be interesting, but I like Dragon's idea best. Anything that is "undocumented", I want to know about: either it is something I need to be aware of (security) or it is useful (e.g. switches in Notes.INI that help with logging etc).
What's the point in re-engineering the Domino Designer client through either the Notes client or the browser? Are you telling me it will be better / quicker / easier? Give up! (That said, I have worked with / designed / improved a template that had fill-in-the-blank fields on forms that were configured for web use (y'know, this field is the ticker, this is the MOTD, this is the first level menu link, this is the second level menu link, etc) ... Jake's thoughts on that would be worth hearing.)
I don't know whether you've noticed it or not, but Domino Designer costs money. While a "pick a type" page designer may have its uses for content management applications, you can't exactly design a "do something" application that way. Designer Lite, as I have envisioned it, would give a hosting organisation the opportunity to deploy a "blank" (other than the Designer Lite parts) database to their server and allow an Editor-level end-user the opportunity to create a fully custom application (that's "application", not just "site") from the ground up WITHOUT paying (what is it now, $CDN 1100?) for a Designer client license, and without allowing room for potentially dangerous or stupidly resource-intensive code. That's the point of "re-engineering the Domino Designer client".
Hi Stan,
no, actually, I hadn't looked at the cost of a designer client as a separate / significant expense.
That said, it is not difficult to design a vanilla website (one of the applications I have designed / implemented / improved / etc) that can be customised.
Maintenance can still be quite onerous (one of the favourite areas for re-write is group calendaring -- nice article on you site, btw). And the end users still have to be taught how to customise the applicaton (how to populate the menus and update the feeds, etc).
How far have you got with your vision? I'm still not sure what benefit you're looking to generate.
Are you thinking of using the C++ API to duplicate Designer functionality?
The point I was making was that it sounds like you're trying to recode the Designer client (written in C) with DHTML and Javascript. I am entirely skeptical that it would even be feasible. But, if you see an opportunity, go ahead -- that's how the free market works. (I'm assuming you've done some market research and there is a bona fide requirement for such a beast.) I'd love you to prove my skepticism unwarranted.
(Actually, if you use Assembler Language instead of C you'll probably find a HUGE potential for improving the performance -- judging by the tools used to compile some of the object code and the wasted space, therein. It's just a project of colossal proportions, and I would be confident that there are better ways to occupy that sort of effort. ;o)
No, all you need is DXL (well, your own XML schema and a XSLT to make the DXL) and LotusScript or Java run-on-server agents. No need to get wrapped up in any flavour of C whatsoever, and certainly no requirements for assembler. DXL gives you everything you need to create and edit Domino Designer elements, at least in a limited fashion, and that what's not covered by DXL (specifically formula string injection/compilation) can be handled directly through LotusScript or Java. DHTML will allow you to create the custom XML browser-side. There's not nearly as much to this as you seem to think, although it is clearly more complex than Arjen had assumed. We're not just talking about creating forms -- there are also views, agents, pages, framesets, etc., to think about. Morphing an all-purpose vanilla form is one thing, but you really need to have access to the other design elements to create a custom application.