Navigating along rapid.xml nodes - rapidxml

This question slightly differs from check for variable number of sibling nodes & different siblings in Rapidxml. In most of the examples I have found on the web I see hard coded keys, for example:
xml_node<>* root = doc.first_node("rootnode");
Here "rootnode" is hard coded. My situation is slightly different, in the sense that parsing and tagging is already done by rapidxml. I need to know the names as read by the parser by iterating over nodes and their sibling without knowing the hard coded name and the depth of the node. I am looking for the suggestion/solution on some kind of recursive navigation along rapidxml tree.
Thank you.

According to RapidXml's documentation (see here) the node name parameter in first_node() method is optional. You can just omit that parameter and you will get the first child node, regardless of its name:
xml_node<>* root = doc.first_node();
Then you can just get node's name by calling its name() method.

Related

How does 'as' work when used inside 'where'?

Learning gremlin and looking at examples I see the use of as inside of where steps to match against a previously labeled step.
For example, from official recipes page, a vertex is labeled 'v' with as, later on inside a coalesce it looks for an inE where the outV equals to 'v', but it does so using as again:
gremlin> g.V().has('person','name','vadas').as('v').
V().has('software','name','ripple').
coalesce(__.inE('created').where(outV().as('v')),
addE('created').from('v').property('weight',0.5))
If I were to just read the reference documentation this query would look to me like they are just labeling that outV step as 'v' and nothing more.
This functionality of as doesn't seem to be documented in the reference documentation, and only shows in the examples with no special mention of it.
Does the previous query achieve the same as the following?
gremlin> g.V().has('person','name','vadas').as('v').
V().has('software','name','ripple').
coalesce(__.inE('created').where(outV().where(eq('v'))),
addE('created').from('v').property('weight',0.5))
Is this just a lack of documentation, or is there something I'm missing?
Is saying as has a special meaning inside 'where', correct? Or is there something else to take into account?
Yes - as() has special meaning inside where(). It is described briefly as part of the select()/where() usage (see item 3) and in the match()/where() usage. Basically when you write your query that way you are using where() with its variable binding form and is equivalent to the more direct form that you demonstrate in your second query. Personally, I tend to find the binding form a bit less readable, but that depends on the nature of the filter I guess and sometimes it represents the most clear way to structure the query.
As you observed, an as step is treated differently inside a where step to allow a step label created outside the where step to be treated as a label inside the where step and not a literal string.
There is a writeup here
http://www.kelvinlawrence.net/book/PracticalGremlin.html#patternwhere

Why window.getComputedStyle in Flow returns `any` type?

According to MDN getComputedStyle(element) returns CSSStyleDeclaration object. But Flow tells that return type of method is any. Can I fix this without writing own type declaration?
It doesn't look like there is any particular reason, just that it hasn't yet been given a better type. You can see in the DOM libdef file that it is declared as returning any, and that line hasn't been touched in over four years.
This would be an easy first PR, if you are interested in improving it.

GNU make: expansion of a deferred construct

On this site containing the documentation describing how make reads a Makefile, there is the following paragraph:
[...]
It’s important to understand this two-phase approach because it has a direct impact on how variable and function expansion happens; this is often a source of some confusion when writing makefiles. Here we will present a summary of the phases in which expansion happens for different constructs within the makefile. We say that expansion is immediate if it happens during the first phase: in this case make will expand any variables or functions in that section of a construct as the makefile is parsed. We say that expansion is deferred if expansion is not performed immediately. Expansion of a deferred construct is not performed until either the construct appears later in an immediate context, or until the second phase.
[...]
I do not know what the highlighted part means.
Does it try to say that if there is a variable reference first found in a deferred section it will not be expanded during the first phase, but if the same variable reference is then found (later in the Makefile) in an immediate context, that variable reference will be expanded? Why would it say this explicitly?
Or does it try to say that there are cases when the exact same line can be read within a different context?
I do not know what the highlighted part means.
Does it try to say that if there is a variable reference first found
in a deferred section it will not be expanded during the first phase,
but if the same variable reference is then found (later in the
Makefile) in an immediate context, that variable reference will be
expanded?
Something like this, but I hesitate to say "yes" because I'm not sure I fully understand you. Instead, I put it in my own words: the manual says that an expression with a deferred expansion is expanded immediately when it is evaluated as part of the value of an expression that is immediately expanded. Example:
INTRO := The messages are
DEFERRED = $(MESSAGE1) literal message
IMMEDIATE := $(INTRO) $(DEFERRED)
MESSAGE1 = deferred message,
demo:
#echo immediate: "$(IMMEDIATE)"
#echo deferred: "$(INTRO) $(DEFERRED)"
Demo:
$ make demo
immediate: The messages are literal message
deferred: The messages are deferred message, literal message
$
Note that variable DEFERRED is expanded immediately as part of the process of setting the value of immediately-expanded variable IMMEDIATE. You can see this from the difference in the output of the two echo commands. You can also see that this expansion does not stick to DEFERRED, which is one of the things that can be confusing.
Why would it say this explicitly?
Because one might suppose otherwise. Specifically, one might suppose that building the "demo" target in the example above would cause two identical lines to be printed. That would require a deferred expansion of DEFERRED being somehow symbolically encoded into the immediate expansion of IMMEDIATE, or else that DEFERRED be somehow converted into an immediately-expanded variable. Nothing along those lines happens.
Note, too, that the two expansions of DEFERRED are different in this case, which is not necessarily a possibility that is immediately evident.
Or does it try to say that there are cases when the exact same line
can be read within a different context?
Inasmuch as I differentiate between identical and exact same, the only way "the exact same" line can be evaluated in different contexts is if it is part of the expansion of a deferred-expansion expression. Then it can appear in both immediate and deferred context, as the text $(MESSAGE1) literal message in the example does. In that sense, yes, the manual is talking about that; it's not different from your other alternative.
It is also possible for distinct but identical text to appear in different contexts, but this is not as interesting.

How to programatically control an object's add-menu list of allowed content types?

I would like pragmatically to control individual objects' add-menu list of allowed content types.
I am building a collection of content types with archgenxml. In one case, I have a simulation class composed of a RangeBase class which has three realizations, valueRange, vectorRange and uniformRange. A simulation can contain exactly one range, i.e., RangeBase's multiplicity is one, so a simulation's add-menu should offer either all three range types or none at all.
To achieve this, I thought to subscribed to the IObjectInitializedEvent and IObjectRemovedEvent events; placing their respective handlers, initializedHook and removedHook, in the RangeBase class. The handlers would solicit an object's list of locally allowed types and remove or add the three ranges accordingly. After perusing the Plone's 'Community Developer Documentation', I thought the initializedHook code might look something like this:
# Set allowed content types
from Products.ATContentTypes.lib import constraintypes
def initializedHook(obj, event):
# Get this range's parent simulation
parent = obj.aq_parent
# Enable constraining
parent.setConstrainTypesMode(constraintypes.ENABLED)
# Remove the three ranges
allowedTypes = parent.getLocallyAllowedTypes()
ranges = ('valueRange','vectorRange','uniformRange')
for range in ranges:
allowedTypes.remove(range)
# Tweak the menu
parent.setLocallyAllowedTypes(allowedTypes)
parent.setImmediatelyAddableTypes(allowedTypes)
Unfortunately, my simulation class has none of these functions.
Is there an adaptor that will provide my simulation class with this functionality, or are there other altogether different approaches to achieve the desired menu behaviour? Any suggestions would be appreciated.
It is possible.
I believe you need to override getLocallyAllowedType()
http://svn.plone.org/svn/collective/Products.ATContentTypes/trunk/Products/ATContentTypes/lib/constraintypes.py
AT was written time before adapters, so AT is not using it.
I suggest you could also update the documentation regarding this... it is pretty common use case.
http://web.archive.org/web/20101010142032/http://collective-docs.plone.org/content/creating.html
After several unsuccessful attempts at tweaking _allowedTypes(), I followed the last suggestion at http://plone.org/documentation/kb/restrict-addable-types and customized getNotAddableTypes.py. My customization merely lists a folder's contents filtering for the three ranges. If the resulting array is not empty, I add the three range types to the list:
# customize this script to filter addable portal types based on
# context, the current user or other criteria
ranges = []
ranges = context.listFolderContents(contentFilter={'portal_type':
('VectorRange','ValueRange','UniformRange')})
return {True: ('Favorite', 'VectorRange', 'ValueRange', 'UniformRange'),
False: ('Favorite')}[len(ranges)]
See the last post here for two possibilities: http://plone.293351.n2.nabble.com/Folder-constraints-not-applicable-to-custom-content-types-td6073100.html
The method
foo.getLocallyAllowedTypes()
gives back a tuple, that you just have to copy / filter into another tuple / list, because it's immutable.
allowed_types = parent.getLocallyAllowedTypes()
filtered_types = []
for v in allowed_types:
if not v in ranges:
filtered_types.append(v)
Then you can just give that tuple to the setter method
parent.setLocallyAllowedTypes(filtered_types)
and your're done. But if you want to access the parent during object creation to restrict content types of the folder, you creating the object in, you can hook up in at_post_create_script() and manage_beforeDelete() from BaseObject. This works great for me, restricting the number of specific content types to a folder and also corrects the AllowedTypes when the object gets deleted.

How to get a LPITEMIDLIST pointer according to the path of a folder?

I want to get the system icon of a specified folder, but maybe the only way to retrieve the icon is to use SHGetFileInfo() method. The first parameter of SHGetFileInfo() method is a pointer of LPITEMIDLIST.
If I only have the absolute path of the folder, how can I get the pointer according to the path?
SHParseDisplayName().
Welcome to the wonderful world of PIDLs.
You can read more at Introduction to the Shell Namespace, but basically a PIDL is a Pointer to an item ID List. You can think of it as a linked list in contiguous memory, but instead of each node having a pointer to the next node, you instead have the cb member which is the Count of Bytes that are contained the item, so you can add that to the base address to get the next item. IDLists are terminated with an item with { cb = 0, abID = NULL }.
So, what's in these magic lits? Basically you don't care and can't know. Any IShellFolder implementation can create a new type of ID to represent its type of item in the shell namespace. The basic file system view that the Shell implements just stores the parts of the path in these lists, so you have something like "c:\" in the first one "Users\" in the next one, etc. In reality they are serialized structs (or classes) that may contain more data. But they can also represent printers, network shares, database searches (for search folders, stacks, etc).
All you really need to know is you can ask IShellFolders to give you a PIDL that represents the items they contain, and later on you can give that PIDL back to them, and other various Shell functions and interfaces, and they know how to deal with them. What SHParseDisplayName() basically does (I think) is go through the registry looking for all registered IShellFolder implementations and asks them if they know what to do with the string you pass in, and the first one to handle it makes the PIDL and gives it back.

Resources