Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

HTTP/REST API documentation?

Avatar

Level 2
Hi,



I need to use custom fields for my users... I see that custom
field must be registered, but the
UserManager.registerCustomUserField(String) requires OWNER role to
be invoked.



Now, I use the client ActionScript API in my Flex
application, but I want to perform administrative tasks in my
server back-end, written in Java (I'm logging in users using
external authentication too). So, how can I define custom fields
using the HTTP/REST API? I can't find documentation on this API at
all, excluding the server script examples.



Thank you



Cosma Colanicchia
13 Replies

Avatar

Level 2
That's a good spot, these methods aren't in the online API
docs, although I've found them now in the code and just what I
need:



UserManager.registerCustomUserField();

UserManager.setCustomUserField();



Are these methods lightly to make it into final API? there's
also a few methods commented as private but set as public;
setUserStatus(), setUserVoiceStatus()... would it be safe to use
them? (not that I need them at the mo)



thxs paddy ;)

Avatar

Level 2
Hi darklump,



I see that those methods are not in the API docs (that's
because of the @private comment, it excludes the element from the
generated asdocs).



My problem is that I can use them in client code (in
actionscript, using the cocomo swc component) but I don't know
if/how can I perform the same thing from a non-actionscript
service, thus using the HTTP API used also by the SDK examples for
other porpuses.



Anyway I'm facing another problem now.. in the meantime I
simply granted the OWNER role to all connecting clients, and
registering the custom field as needed like this:



var um:UserManager = myCocomoSession.userManager;

if (!(um.isCustomFieldDefined("myfield"))) {

um.registerCustomUserField("myfield");

}

um.setCustomUserField(um.myUserID, "myfield", "value");



I thought that this would have triggered the UserManager's
event

UserEvent.CUSTOM_FIELD_CHANGE, but it didn't. So I just
explicitly tried to retrieve the value:



private function refreshUserFields():void {

var um:UserManager = myCocomoSession.userManager;

var dsc:UserDescriptor = um.getUserDescriptor(um.myUserID);

var myfield:String = um.customFields["myfield"]; // always
null

}



But the customFields atrribute is always an empty Object. I
noticed that the flash console displays the following each time I
try to set the custom field value:



RECEIVENODES UserManager

receiveAllSynchData UserManager



Is the customfield stuff experimental/in progress or I'm
wrong somewhere?

Avatar

Level 2
Ok, found the problem.



If anyone is interested, the custom field values are not
managed because the line 848 of UserManager.as is commented out..
probably this is a work in progress (explaining also why methods
are not documented).



Guess I'll need to manage the additional user info in some
other way.

Avatar

Level 2
hey Cosmacol, I would have thought add extrenous User info is
quite an important feature for Cocomo. i.e how to set a user as
'busy' or 'Away from computer' (think Skype) so before you give up
I'd wait for a offical response from Adobe as I'm sure there will
be a suggested way to do this within the framework? it might be as
simple as adding an 'extras' generic object property (like how
papervision3d does which is useful)?...

Avatar

Level 3
I wonder as well, even to add some extra info on the user,
his firstname, lastename etc ..

Avatar

Former Community Member
Hi,



Yes this field was commented out for other reason in the
previous release as it was not fully functional. See this thread
how you can use CustomUserField for this release.


http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=72&catid=759&threadid=1407726&h...



It has been fixed and it will be functional in the next drop
of SDK.



Thanks

Hironmay Basu

Avatar

Former Community Member


@cosmacol : We're definitely looking at ways in which your
Java server would be able to administer in-room details of the app.
We'll be able to talk about this a little more later.

Avatar

Level 2
@Hironmay: thank you, I'll try your setup as soon as I get
back to work next week.. I was able to get those custom attributes
associating a second NodeCollection to the same shareid and
listening for events, but it probably is a dead end.. by the way,
do you know when will the next beta drop happen?



@Nigel: it would be very nice... I'd prefer to not pass OWNER
authentication tokens to actionscript clients running on client
machines in order to perform the required setup/initialization room
tasks

Avatar

Former Community Member


Hi cosmacol,



Actually, if you set up customUserFields (which you'll have
to either hack or wait until the next beta drop to do), you can
then set up the room in question as a template for your subsequent
rooms. This way, the next time you generate a new room, you can
choose the "room with custom user fields" template, and the new
room will be created with nodes pre-set up for doing the fields you
wanted. In that case, you wouldn't need an OWNER to set up every
time.



hope that makes sense (it's a bit hard to describe).

nigel

Avatar

Level 2
Nigel,



your explanation is pretty clear, thanks for pointing it out
- we've have not explored the room templating features yet, but
we'll surely consider this option... even if I'd still prefer being
programmatically in control of configuration tasks :)



And thank you for all the support and feedback!



Cosma

Avatar

Level 2
@Hironmay



The classes in the other thread worked very well. I just add
to workaround a simple problem. I use the "custom user detail"
object as a bag for storing multiple values, setting values like
this:



var details:Object =
_userDetails.getCustomUserDetail(p_userID);

if (!details) {

details = new Object();

}

details[attributeName] = value;

_userDetails.setCustomUserDetail(p_userID, details);



This could fail, because the getCustomUserDetails does not
reflects immediately the values just set until it receives a
message back from the cocomo server. So, if you try to write more
than a single attribute before this refresh, the previous one is
lost.



This is a quick hack this loss of data, modifying the
onItemReceive method of CustomUserDetails.as

Avatar

Former Community Member
Hi,



Yes i agree with you, so you can locally cache it so that
even if you try to set it again immediately , it should be fine.



Thanks

Hironmay Basu

Avatar

Level 2
Yes, finally I added a simple local cache - with my previous
(posted) code, the cocomo server ended up having only the last of
the custom attributes set (even if the submitting client has all),
causing troubles for new connecting users.



Thank you

Cosma Colanicchia