I would like to access the underlying lists (before and after) based on detection of a ListChange when diffing two entities. All I have direct access to is the list elements that have changed through ContainerElementChange.
Other PropertyChange types accommodate this, but unfortunately ListChange does not appear to.
Is this possible?
No, there is no access to underlying lists from ListChange items.
We had some discussion about this in last year (see https://github.com/javers/javers/issues/202) concerning ArrayChange.
You can put a feature request to our issues.
Related
I added a linked fact using:
context.InsertLinked(longOrderKey, longOrder);
At some point later, I want to remove this fact. It's easy for me to construct the key without having the record:
var longOrderKey = (managedAccount.AccountId, PositionType.Long, fungible.FungibleId);
So why do I need the record when removing a linked fact using the method:
context.RetractLinked(longOrderKey, longOrder);
Why can't this method just use the longOrderKey? What if I don't have the 'longOrder' record. Do I really need to look it up before I can remove it?
Linked facts are tied to an activation that created them. The purpose of the key is to be able to identify the specific fact if the activation produced more than one linked fact. If you are inserting just one linked fact in the RHS of a rule, you can really set the key to anything, e.g. "1"; if you were to insert two facts, you could set keys to "1" and "2", and so on. In essence, the key is to identify the linked fact within the activation. The fact itself is needed, so that the engine can find the corresponding entries in the working memory. Much like ISession.Retract requires the fact object, so that it can find it in the working memory.
Another point is that in most scenarios you should not need to retract the linked facts as they would get retracted automatically, once the activation gets deleted (i.e. the conditions that created the activation become false).
I'm implementing a native iOS application, which provides a feature to search for articles using keywords and several search filters such as author, year, publisher etc. Each of these search filters has several options such as 2014, 2013, and 2012 for the year filter, or Academe Research Journals, Annex Publishers, and Elmer Press for the publisher filter. Each of these options has a BOOL stating whether the option is selected or not. I need an object that wraps the search keywords and search filters so that I can send it to the server, which is responsible for the search operation.
Which data structure should I use to represent these search filters in the wrapper class?
Something like XML comes to mind:
<year>2014</year>
<publisher>Annex Publishers</publisher>
Although I find it rather bulky. I'd probably prefer something like:
year=2014|publisher=Annex Publishers
You'll need to escape = and | appearing in the field names or values, but this is easy to do.
This could just be a single string sent across.
In terms of actual data structures, you could have a map of field name to value, only containing entries where the option is selected. Or you could have a class containing pointers / references for each field, set to null if the option is not selected.
Another totally different consideration is to use an enumerated type, i.e. mapping each possible value to an integer, typically resulting in less memory used and faster (and possibly more robust) code, depending on how exactly this is done.
You could map it as follows, for example:
Academe Research Journals 0
Annex Publishers 1
Elmer Press 2
Then, rather than sending "Annex Publishers" as publisher, you could just send 1.
year=2014|publisher=1
The extension for multiple possible values for a field can be done in various ways, but it's fairly easy to do:
<year>2014</year>
<year>2013</year>
<publisher>Annex Publishers</publisher>
Or:
year=2014,2013|publisher=Annex Publishers
Is there a data structure within LiveCode that can be used as a "holder" for associated data, letting me handle it collectively? I come from a Java / Javascript / C background so I am looking for a Class or Struct sort of data structure.
I've found examples of Groups, which seem to have some of this functionality, but it feels a bit like I'm bending the language to meet my needs.
As a specific example, suppose I had an image field on my screen that would randomly display an image and, when pressed, play an associated sound clip. I'd expect to create a list of "structures" that contained the path to the image and the path to the associated sound clip, and use that data to populate the image field and to decide what sound clip to play.
Would a Group be the correct structure to use in this case? Or am I approaching this in a way that isn't really fitting with the way LiveCode works?
It takes a little getting used to, but the xTalk world is much simpler and more open than any ordinary procedural language. So much of what you once had to manage is no longer required.
So when splash21 said that you could store all your image and sound references in a custom property, he was really saying that the LiveCode environment contains intrinsic, high level functionality that makes these sorts of things instantly accessible, and the only thing required of you is to call for them, and they simply work.
The only way to appreciate this is to make a few simple programs, to really see what is possible. Make your application. Everything you mentioned can be accomplished with perhaps a dozen lines of code in a single handler. I recommend that you join the LiveCode use list and forums. The community is vibrant and eager to help, frequently with full blown solutions to specific problems, but more importantly, as guides and mentors to new users
Craig Newman
Arrays in LiveCode are actually associative arrays (like hash maps). A key is associated with a value. The value might be as well an array.
Chapter 5.5.7 of the User's Guide says
Array elements may contain nested or sub-elements, making them multi-dimensional.
This type of array is ideal for processing hierarchical data structures such as trees or
XML. To access a sub-element, simply declare it using an additional set of square
brackets.
put "ABC" into myVariable["myKeyName"][“aChildElement”]
see also
How to store pictures in a stack?
Dave- I'm hoping to get a struct-like container implemented in the near future. Meanwhile you can, as splash21 mentioned, use custom properties (or better yet, custom property sets) to do what you want. This will give you a pseudo-struct for each object and you can implement the file and sound specifications into the properties. And if you use that in conjunction with a behavior object you'll end up very close to a real inheritable class formation.
My project calls for something similar to yellow pages:
Storing users services and providing look-up by service.
My current solution is very rigid and cumbersome -
I have 3 preset lists: Industry, Trade, Specialty.
User starts at top level and defines his service(s).
I also create a "search in place" option where providing strings performs a look-up in the string of "Industry - Trade - Specialty".
I noticed Google, LinkedIn and yellow-pages provide a much easier solution where users can put in free text, and the system will give results for Certified Public Accountant even if search term is CPA.
Any thoughts on a smarter, more efficient and easy for the user solution?
I am not looking for the exact db structure, the general algorithm will suffice.
Thank you.
Have you considered a tag structure? That allows entries in multiple places, tag hierarchies, tag "remaps" (standardize tag names).
Basically, you do NOT have a hierarchy in - entries are flat, but have tags attached that can form hierarchies. This is flexibility you need - a company may provide multiple services, you may want to have tags standardized, too.
Simply said:
A table (or more - I keep it general) for the entries
A table for tags, parenting itself (form a tree)
An EntryTAble tag.
The tag table must allow crosslinks (alternative tag, status etc.).
I'm refactoring one of my projects - a shopping cart. One of the tightly coupled areas of my code is the "Viewer" class - to generate information for the user to see, it often needs a combination of two or more of the following objects:
The store catalog.
The customer's order.
The customer's mailing information.
I can't really break up the display methods, for various reasons.
Martin Fowler's Refactoring identifies this as a "Long parameter list" smell. The relevant refactoring here is "Introduce parameter object." I am, however, hesitant to do that, as doing so would couple loosely related data. It would also lock me to a very narrow one-to-one relationship between those three objects - while that would work for my application as it is now, it makes no real-world sense. (As there is only one store catalog, there can be many "Customer mailing information" objects, and each of those may be related to many "Customer's order" objects).
Does anyone have any elegant solutions to this?
A parameter list of three parameters needs no refactoring. Start worrying when you reach, say, 8 or 10 parameters.
Try to name the thing that binds a catalog, an order, and an address. Start, maybe with CatalogOrderAddressTuple. Ugly, isn't it? Well, maybe as a utility class of your Viewer, it should just be an inner class, where you could get by with just Tuple - or Data. Still ugly.
It doesn't sound like these belong as actual fields to the Viewer - but explore what that would look like, how your code would change if each Viewer were simply constructed with the data on which it operates.
As ammoQ & Ryan Prior have said, this isn't much of a smell, but I'd say it's worth playing with some alternatives before giving up entirely.
As stated by ammoQ, looking for refactoring opportunities with so few parameters is stretching.
See also: KISS and YAGNI.
It seems to me that introducing a parameter object would have the opposite effect of locking you to a one-to-one relationship between those three objects.
If a single customer address is being passed around, and in the future someone decides to separate billing address and shipping address, then it would probably be simpler to add the new address to a parameter object, rather than add a new parameter up and down the call stack.
(This is just an example, of course. Ideally, the address information would exist separately in the order and customer objects, since all information on posted orders should be immutable, even if the customer's address changes. But that wasn't what you were asking about!)