I'm creating an application in which users can create notes that are displayed in a grid. When a note is created, a corresponding text file is also created. When a user opens the application, the application reads the directory of note files, retrieves the content of each note file, and then displays it in the grid.
The idea is to make the grid of notes rearrangeable via drag-and-drop.
I've never done anything this before, so I'm struggling to devise an efficient way to cache or remember the order in which the user has arranged the notes. I thought of storing the position of each note in the filename itself.
1_note3.txt
2_note7.txt
3_note4.txt
4_note2.txt
5_note6.txt
6_note8.txt
7_note5.txt
8_note1.txt
This doesn't seem like a good approach since, anytime the the notes are rearranged, I'll have to rename a bunch of the files. For example, say the user creates a new note — which would be inserted as the first child of the grid for the sake of user experience — all of the filenames would have to be renamed.
1_note9.txt
2_note3.txt
3_note7.txt
4_note4.txt
5_note2.txt
6_note6.txt
7_note8.txt
8_note5.txt
9_note1.txt
Further, say a user now rearranges the notes by moving the first note to the fourth position in the top row. I'd now have to rename that file and all of the following files.
2_note3.txt
3_note7.txt
4_note4.txt
5_note9.txt
6_note2.txt
7_note6.txt
8_note8.txt
9_note5.txt
10_note1.txt
I could also store the order or arrangement in a separate file, and exclusively manipulate the content of this file instead of the actual filenames.
arrangement.txt
note3.txt
note7.txt
note4.txt
...
Although this may be superior to the last approach, it also doesn't seem that great since there is still additional overhead. For instance, when the application is launched, I'll first have to read that file in order to obtain the user arrangement before sorting files accordingly.
Does anybody have any experience implementing something like this? Is there a better way to go about it?
You may like to maintain state of your note grid in a key-value map data structure. you can cache this map in-memory or persist it in a separate file. This key-value map will store note grid data where "Key" will have position order in the grid and "Value" will have name of the corresponding text file. In case notes are rearranged you only need to update value of two keys.
Related
Sorry this isn't a specific coding question, it is more of a design concept.
What is the usage case for programmatically adding and removing fields to Notes Forms e.g. NotesDocument.RemoveItem(), ie why would you add and remove fields in the background?
For many years I have designed my forms with the fields layed out on the form which are required and then hide and show as required.
By adding dynamically you can't position them and frustratingly removing them or deleting they still appear the Database Fields in Domino Designer, getting rid of them is a bit a a black art, but that's another story.
I must be missing a trick or a basic design concept. Any thoughts on best practice would be appreciated.
Many thanks.
Yes, you are missing the difference between "Fields" and "Items". A field is a design element that you can place anywhere on your form. You define how it looks, what content it contains, what datatype it is, etc.
When creating a document with the form the value of the FIELD is stored in an ITEM in the resulting NotesDocument.
This item is totally decoupled from the field that created it. If you were to change the field in the form from text to number or move it around or make a names- field of it, the item in the existing documents would never change unless you open the documents and save them in frontend or use any LotusScript or Formula Code to recalculate the document in backend.
Very often items are added programmatically to documents to fulfill different purposes: Calculate values to be displayed in views, calculate values that are import for the workflow but not for the user, etc.
Complex applications often consist of a lot more items than there are fields in the several forms.
Back to your question: Removing an item from a document simply removes the value that was created by the field in the form. When reopening the document, the item will be repopulated, either by default value or whatever....
Usually you would use this to remove items that you no longer need (and probably already removed from the form).
As soon as you removed all references to a field / item everywhere in design and documents, you can finally get rid of it completely by compacting the database.
An item is distinct from a field in Notes. The form is purely a UI concept, the item is what the data is stored in.
Manipulating data in the backend can be used for a number of reasons. One such use case is the setting of a flag when a date on the form has expired.
Say you want a view showing all documents that have expired. Your rules dictate that documents are considered as "Expired" after 7 days. You could create a view with a formula that shows all document whose date is 7 days older than today:
SELECT Date < #Adjust(#Today; 0; 0; -7; 0; 0; 0);
This view will ALWAYS be out of date and will constantly be updated by the server as it re-evaluates #Today.
Now, a better way would be to create an agent that runs daily that sets an item on the document to indicate that it has expired e.g.
#SetField("Expired"; 1);
The view formula would then be
SELECT Expired = 1
The view would only need to update daily and you have a much faster view because of it.
RemoveItem is used to get rid of data no longer needed e.g. FaxNumber.
There are many use cases for RemoveItem. Here's one that comes up frequently.
You have a database and an agent that processes documents in that database. Every time it runs, the agent replaces the value of a bunch of items. There are a variety of error conditions that can cause it to abort processing a document early, but you're a smart programmer and you've accounted for that with on error traps. When you hit one, you log an error message, save your document, and then either abort your agent or go on to processing the next document.
But at this point, some of the items that the agent normally updates have values saved from this run, and some of them have values saved from a previous run. This might be bad. This might be confusing for someone who is looking at the item values and trying to figure out what's going on. This might even cause validation errors on the form.
So how do you avoid this? At the very beginning of your agent, you call a cleanup sub that finds and removes all the items that the agent is going to update. Now you have a clean slate, and if your agent hits that error condition, it can save whatever it can save without any concern about whether it is leaving things in an inconsistent state. Of course, in cases where you are doing this to avoid validation errors, your validation formulas will have to be smart enough to be checking #IsAvailable for dependent items, but that's a good practice anyhow.
I am automating Sharepoint list testing, filling up some field with values,
and like to save data I supplied to the field after.
Is there a way to automate saving the field value in a excel or csv?
In order to keep it simple, I would create two recordings and write to a text file (csv).
The first one would get the text values from the desired fields and return them in bound variables using Ranorex GetValue action.
The second recording would write the content of the bound variables to a text file, separating fields with ',' (or any other character that is suitable for the kind of data that is present in the fields) in a user code function.
If you have no idea how to write to a file in .NET, take a look at System.IO.File.AppendAllLines or similar functions.
You could also combine the 2 recordings in one, but then, re-useability would be limited the scope of the SharePoint page you are testing.
Do not forget that since Ranorex is using the .NET framework, you have access to all the functions provided by the framework in user code. With Ranorex, the usual question is not ask if something is possible. The real question is "how can it be done" and is the solution simple enough for testers to be able to use it!
Hope this helps!
I have searched for current solutions, but can't find a set of guidelines or examples as to how to achieve the following:
The original requirements involved models with required fields, so we included annotations to those fields. As usual, there is a last-minute change and we are being asked to allow the users to save drafts. These drafts must allow the user to save the forms without any of the required fields.
I would like to know what the best practices for this problem are.
Solutions I am considering, but I accept they might be a hack (and that's why I am asking the experts)
If the user clicks "Save as Draft" I can capture the fields that have information in another ActionResult and run basic validation on those fields. Since there is a chance that required fields are missing, I am thinking in storing the captured info in a temporal model (without any required annotations). If the user decides to edit such form, I can populate fields in the view with the temp. model until the user clicks on "Submit"
Another option is to remove all required annotations and run client-side validations... but am wondering on the amount of work required to do so.
Any thoughts are very much appreciated.
Just have 2 save methods. 1 which is called from the autosave and 1 that is used to submit the process. In the autosave method do not check if(ModelState.IsValid).
Whether you choose to save the incomplete objects to the same table or a different table is your choice. In a relational world I would likely use a separate table, in a non-relational world I would use a singular object collection.
This will allow you to keep the same set of original models. There is a very high cost to duplicating your models, there are certainly times that warrants pass by value/copy but make sure the cost of mapping is there. In this situtation I do not believe there is value in mapping, except perhaps at the persistence level if you need to map to a different object because of an ORM's constraints.
There is deep value in these partial forms. Recording this on the server will allow you to apply analytics to learn why your users abandon your processes. It also gives you the ability to follow up on users who leave incomplete forms such as sending a reminder (nag) email.
You don't want to save anything to your database until it is complete. Having a duplicate table where everything is nullable is cludgy as hell. Before HTML5, the typical path was to save the information to the session, which you could then pull from to refill the fields, but that's requires having a session with a relatively high expiry to be useful.
Thankfully, HTML5 has local storage, which is really the best way to handle this now. You just watch for onchange events on your fields and then insert that value into local storage. If the user submits the form successfully, you destroy the local storage values. Otherwise, you attempt to read those values from local storage when the page loads and refill the fields.
See: http://diveintohtml5.info/storage.html
There's pretty broad support, so unless you need to worry about IE6 or IE7, you won't have any issues.
Another option (depending on your data obviously) would be to comply with the database but not the model. By this I mean ignore Model.isValid and disable Javascript validation on the front end but then satisfy the database table. In a form, you mostly have:
textboxes - default to "" or " "
checkboxes - easy true/false default
radio buttons - one is probably already selected
dates - default to DateTime.MinValue (or DateTimeUTC)
enums - default to 0 (usually for 'unspecified')
Hopefully you are also saving a flag designating that it is in Draft state so that you know you need to interpret the 'null codes' you have set when it comes to displaying the semi-populated form again.
I'm currently writing an application that moves Notes documents between databases based on the amount of days that have elapsed from the creation/modified/last accessed dates. I would just like to get ideas on a simple and convenient way to create documents with specific dates, without having to change the time on the Domino server, so that I could test out my application.
The best way I found so far was to create a local replica and change the system clock to the date I want. Unfortunately there are problems associated with this method. It does not work on the modified date - I'm not sure how it is getting the modified date information when the location is set to Island (Disconnected) - and it also changes the modified and last accessed dates when the documents are replicated to the server replica.
Someone suggested trying to create a DXL of the document, modify the date time in the DXL file, then import it back into the database as a Notes document; but that does not work. It just takes on the date-time that it was created.
Can anyone offer any other suggestions?
You can set the created date for a document by setting the UNID (which is fundamentally a struct of timestamps, although the actual implementation has changed in recent versions). Accessed and modified times, though, would be unsettable from within the Notes/Domino environment, since the changes you make would be overwritten by the process of saving the changes. If you have a flair for adventure and a need to run with scissors, you could make the changes in the database file itself either programmatically from an external application, or manually with a hex editor. (Editing the binary will work -- folks have been using hex editors to clear the "hide design" flag safely for years. Keep in mind that signed docs will blow up badly, and that you need to ensure that local encryption is off for the database file.)
There's actually a very simple way to spoof the creation date/time: just add a field called $Created with whatever date/time you want. This is alluded to in the Notes C API header file nsfdata.h:
Time/dates associated with notes:
OID.Note Can be Timedate when the note was created
(but not guaranteed to be - look for $CREATED
item first for note creation time)
Obtained by NSFNoteGetInfo(_NOTE_OID) or
OID in SEARCH_MATCH.
Unfortunately, there's no analogous technique for spoofing the mod or access dates. At least none that's ever been documented, as far as I know.
I imagine given how dependent Lotus Notes is on timestamps (for replication, mainly), there isn't an API call that allows you to change the modified, created, or last access dates of a note. (More on the internals of Lotus Notes can be found here.)
I dug around the Notes C API documentation, and found only one mention on how to get/set information in the note's header, including the modified date. However, the documentation states that when you try to update that note (i.e. write it to disk), the last modified date will be overwritten with the date/time it is written to disk.
As an alternative, I would suggest creating your own set of date items within the documents that only you control, for example MyCreated, MyModified, and MyAccessed, and reference those in your code that moves documents based on dates. You would then be able to change these dates as easily as changing any other document item (via agents, forms, etc.)
For MyCreated, create a hidden calculated form field with the formula of #CREATED or #NOW. Set the type to computed when composed.
For MyModified, create a hidden calculated form field with the formula #NOW, and set the type to computed.
MyAccessed gets a bit tricky. If you can do without it, I suggest you live work with just the MyCreated and MyModified. If you need it, you should be able to manage it by setting a field value within the QueryOpen or PostOpen events. Problems occur if your users have only read access to a document - the code to update the MyAccessed field won't be able to store that value.
Hope this helps!
One of the fields in my user profiles is a list of nodes. (This list is generated automatically, based on other data on the site.) Currently, it displays like this:
Nodes
nid1, nid2, nid3
I want it to look like this:
Nodes
$nid1->title, $nid2->title, $nid3->title
where each title is a link to its node. What is the best way to do this? I tried filling the field with links generated by l(), but the html gets filtered out.
Also, when using l(), is there a way to say: create a link to the node with $nid, no matter where it happens to be located at runtime?
Concerning the first question:
The field values of a profile list are run through ´check_plain()inprofile_view_field()`, so you can only get markup in there after they got loaded, which leaves you with at least two options, depending on where you want to alter the output:
Implement hook_user() and, on the 'view' operation, modify the field values in the $account->content array (Make sure that your modules weight is below that of the profile module or the values will not be in there yet).
Add your own preprocess functions for all templates where the fields are used and make your adjustments there. On first sight, these should be the following, but the list might be incomplete:
yourModule_preprocess_profile_block() (profile module)
yourModule_preprocess_profile_listing() (profile module)
yourModule_preprocess_user_profile_item() (user module)
As for the second question:
Also, when using l(), is there a way
to say: create a link to the node with
$nid, no matter where it happens to be
located at runtime?
I do not understand what you mean by "no matter where it happens to be located at runtime". Anything that is not covered by the following?
l('SomeTitle', 'node/' . $nid)