Looking for something to change a mode or parameter based on value of register bit(s). Something like an 'on_modify' for a bit collection. Does that already exist?
I don't think so, though the reverse (update a parameter and have it reflected in the register) is supported if that is any good to you.
See the last example about binding register bits to a live parameter here - http://origen-sdk.org/origen//guides/models/parameters/#Live_Updating_Parameters
Adding some new functionality to bit collection so that it supported something like the following API should not be too difficult:
my_reg.my_bits.on_data_changed do |data|
do_something.based_on(data)
end
The on_data_changed method would just store the given block in the bit collection instance and then trigger it whenever the write method is called.
Related
I feel like I'm just not understanding something about the XPages lifecycle here. I have an xp:text control, with a value of viewScope.count. Initially, that's null. After the xp:text, I have a repeat that's performing a calculation and returning an array of objects for its value. At the end of the repeat's value section, I'm trying to update the xp:text with a count of the things in the array:
viewScope.count = myArray.length;
The xp:text isn't being updated with that value, though. Should this work? Do I need to do a manual refresh of the xp:text when I modify viewScope.count? TIA!
You should be able to use the index of the repeat to give you a count.
Take a step back and rethink the approach. Inside the code you use for your repeat you update something outside.
Not looking at 'does it work' I would claim 'bad idea'. Such side effects make maintenance a nightmare (and are not very MVC).
The better approach (IMHO):
Create an object data source. AFAIK that can be a JSON object if you are not comfortable with Java. That object would have all the needed properties for your repeat and your counter display. It serves as your model.
Then bind the repeat and the text field to the model and you are good.
Makes sense?
I have question regarding session.evaluate in SSJS. In a keyword document I have some #formula stored which does some conversion of data. Lets say this is would be:
#left(fieldname;2)
If the fieldname contained 'hello' this would result in 'he'. Nothing to fancy here. Now I would like to use this in an xpage.
I wrote a function called executeFormula(doc). I call this function from an action on a xpage. This xpage contains 1 notes document datasource. The function call is
executeFormula(datasource.getDocument(true))
Now for some reason the #formula is never calculated correctly. Do I need to save the document first before I can use session.evaluate(kwFormula,doc) or is the #formula wrong in some way?
p.s. I forgot to mention that this code is working inside a customvalidator
Without seeing the code for the executeFormula(doc) function it is very difficult to know exactly how session.evaluate is being called.
I would suggest taking the function out of the equasion for the moment and create a simple test page with the document source and a simple computed field with the session.evaluate in it so that you can see the result. Given your examples above the computed field would be something along the lines of
session.evaluate("#Left(fieldname;2)",xspDoc.getDocument(true));
Once you get acceptable results back then you can move it into your function and verify that it is working there also.
Don't forget that session.evaluate returns a vector so you may beed to do a .getFirstElement() on the returned value if it is not null.
If you're using it in a custom validator, the values posted from the browser/client haven't updated the data model (in your case, the document) yet. This happens after validation is successful.
I imagine it might work for some fields (e.g. fields that are updated after a successful refresh, or stored fields in an existing document).
Actually no need of mentioning the document, eg:- session.evaluate("#username") is enough.
For yours session.evaluate("#left('hello';2)") will work.,
I am doing a workflow for a document library. I put a OnWorkflowItemChanged, and I want to get the value of the column which is changed. I use the workflowProperties.Item["name"] and use the afterProperties. But when I use the workflowProperties.Item["column name"], I still got the original value. When I use the afterProperties, it's NULL.
Then I make another workflow that is the same as above for a list. I can use the workflowProperties.Item["column name"] to get the new value in OnWorkflowItemChanged.
Has anyone come across this problem before? Can you give me some help?
The question seems to mix up Item with ExtendedProperties. As to why a difference is seen on a List/Document Lib, it might have something to do with versionining or perhaps the internal serialization is different. Anyway, some of my experience is outline below. I hope it may be of use:
Use the GUID (as a Guid object, not a string) to access the Before / After ExtendedProperties field. Using the Display Name in the ExtendedProperties will not work. The documentation on it is wrong. You can use SPList.Fields to go from Display Name to Column ID (Guid).
I bind all "Before" to MyWhatever_PreviousProperties and all "After" to MyWhatever_Properties, only accessing MyWhatever_[Previous]Properties after the appropriate event(s)).
Hopefully there's a solution/patch to SubSonic SimpleRepository where I can specify a column/property with a default value so that it populates the DB with the default value set.
I'm still reading the SubSonic Docs and just ran across that issue. Maybe someone has an answer/solution for this that I can start using.
If you want a default value then set it on your object - an attribute shouldn't be used to set values.
Looks like you nailed it... In your class, simply set the default value in the constructor...
You could also set the value as a default in the appropriate DB column.
To my knowledge this feature doesn't currently exist in SimpleRepository and in my opinion it doesn't belong there. I like the SimpleRepository because it's so simple. You don't need to know about or understand a ton of configuration options or attributes; you just plug in your POCO objects and go. There are a handful of attributes that you can use to influence the underlying database table schemas, but I think that a good job was done with respect to keeping those attributes to the absolute bare minimum needed.
If you need to set 'default' values for some reason I think that's something that should be done within your "domain" related code. Setting them in the constructor of the object might make sense, or using a wrapper repository object that could set them prior to passing along to the SimpleRepository could also work. I've always kind of thought that having default value constraints defined in the database was a bit of a smell anyway; it won't always be immediately evident where that value came from or why it was chosen.
Is there a way to use form fields that does not correspond to database field for temporary processings?
I.e. I want to add:
temp fields item1, item2
database field sum
button with record hook that sets sum = item1 + item2
As far as I know it's simply not possible with ClearQuest.
I've tried to do something similar and was told by our IBM consultant that the only way is to create a DB field for all variables.
You can't attach data to form fields really - those are representations of the underlying data, not something scripts interact with directly.
Adding temporary data to the underlying record (entity) itself sounds unlikely as well. Perhaps it's possible to abuse the perl API and dynamically attach data to entity objects but I personally wouldn't try it, you're liable to lose your data at the whim of CQ then ;-)
That does not however mean it's impossible to have temporary data.
The best way seems to me to be using the session object, which is explicitly intended for that purpose.
From the helpfile:
IBM Rational ClearQuest supports the
use of sessionwide variables for
storing information. After you create
sessionwide variables, you can access
them through the current Session
object using functions or subroutines,
including hooks, that have access to
the Session object. When the current
session ends, all of the variables
associated with that Session object
are deleted. The session ends when the
user logs out or the final reference
to the Session object ceases to exist.
There's some helpful documentation on this subject in file:///C:/Program%20Files/Rational/ClearQuest/doc/help/cq_api/c_session_vars.htm (Presuming a default installation on a windows machine, of course.)
Translating the code example in there into what you seem to be wanting, first you store the data you have calculated inside the session object:
$session->SetNameValue("item1", $value1);
$session->SetNameValue("item2", $value2);
Then in your calculation hook you retrieve the stored values and set the value of that totals field like this:
my $item1 = GetNameValue("item1");
my $item2 = GetNameValue("item2");
my $sum = $item1 + $item2;
$entity->SetFieldValue("some_totals_record", $sum);
Adjust to taste of course ;-)
ClearQuest schema designers often include 'temporary' fields in their record types. They do this so they perform operations on hooks to generate another value.
For example, for the Notes fields, there is a 'temporary' Notes_entry field that the user types the most recent note into, and when the record is saved, the value is added to the Notes_Log field. The next time the record is edited the Notes_entry field is cleared so the user can type a new Notes_entry.