7 Gedanken zu “An Alfresco Developer’s Challenge and Journey”

1. Hi Andreas,
   mmmh — really dirty, isn’t it?
   mod­i­fy­ing the processs­de­f­i­n­i­tion is OK, but why didn’t you add a tiny Javascript exten­sion to replace org.alfresco.repo.site.script.Site.inviteNominated?

2. Hi Jan,

   I tried to make clear that the solu­tion intro­duced may not be the most beau­ti­ful one in the world and I’m not proud of it.

   org.alfresco.repo.site.script.Site.inviteNominated calls

   pub­lic Nom­i­nate­d­In­vi­ta­tion inviteNom­i­nated(
   String invi­teeUser­Name,
   Invitation.ResourceType resource­Type,
   String resource­Name,
   String invi­tee­Role,
   String server­Path,
   String accep­tUrl,
   String rejectUrl) ;

   defined by Invi­ta­tion­Ser­vice (inter­face) imple­mented in Invi­ta­tion­Ser­vi­ceImpl. Para­me­ters seman­tics look fairly strict to me and I don’t see a clean way to get the addi­tional infor­ma­tion through here.

   Or are you sug­gest­ing to bypass InvitationService ?

3. Hi,
   no, not bypass­ing:
   1.) cus­tom JS exten­sion with a method appro­pri­ate to your para­me­ters & calls Cus­tom­Site­Ser­vi­ceImpl (= bean site­Ser­vice)
   2) Cus­tom­Site­Ser­vice exten­tends Site­Ser­vi­ceImpl & declares cus­tom inviteNom­i­nated method
   3.) Cus­tom­Site­Ser­vi­ceImpl extends Site­Ser­vi­ceImpl, imple­ments Cus­tom­Site­Ser­vice with imple­mented cus­tom invi­ta­tion logic…

4. sry, I meant Invi­ta­tion­Ser­vice not SiteService…

5. Ok, but pro­vid­ing a cus­tom inviteNom­i­nated method effec­tively bypasses dec­la­ra­tions of the inter­face, right ?

   That would have been fine with me in this case — Javascript does not care about inter­faces any­ways. I even con­sid­ered doing this in the beginning.

   Abon­doned the idea because I felt bypass­ing an inter­face is ugly and con­fus­ing. :) Besides the method doing the heavy-lifting in Invi­ta­tion­Ser­vi­ceImpl (as shipped) is

   pri­vate Nom­i­nate­d­In­vi­ta­tion startNominatedInvite(…)

   It has almost the same para­me­ters as inviteNom­i­nated and rougly 250 LOC, so this class does not really make a good can­di­date for subclassing.

   That was the time I con­cluded it would be over­all eas­ier and safer to abuse a String para­me­ter. :) I chose accep­tUrl because I was fairly sure, its only pur­pose is to get ren­dered into the email.

   Either way, at this point you are only half way down the rabbit-hole, you still have to pass the BPM layer, ren­der the mail text, and set head­ers and content-type.

   Thanks for commenting.

6. Nice exposé about the draw­backs of a pretty hard-set/-coded inter­face and work­flow. This reminds me of the efforts that we once had to put into adding cus­tom per­mis­sions to an Alfresco sys­tem, restrict­ing what kind of site roles could invite other users using role-based restricted lists of invi­tee roles to choose from.

   Con­sid­er­ing the project para­me­ters you explained I find it an accept­able solu­tion. In terms of using the accep­tUrl as your “trans­port medium” I would tend towards using the trans­ac­tion con­text instead (Alfres­co­Trans­ac­tion­Sup­port instead of the men­tioned ThreadLocal).

   I per­son­ally do not like cus­tom exten­sions of Alfresco ser­vices as I have seen too many exam­ples that vio­late inter­nal ser­vice con­tracts. Facad­ing in com­bi­na­tion with trans­ac­tion con­text data or imple­ment­ing a con­tributable patch to the OOTB ser­vice are my pre­ferred options. In terms of the Invi­ta­tion­Ser­vice I could see a sim­ple API exten­sion which would allow pass­ing of a cus­tom data / prop­erty map, pro­vide a “map-to-workflow map­per strat­egy” and a “mail / noti­fi­ca­tion action” exten­sion point (del­e­gat­ing based on site type / state evaluators).

7. Thanks for your feed­back, Axel.

   Funny, it reminds you of secu­rity related efforts you had. I am right now fac­ing require­ments to extend the Share Site secu­rity model. :)

   For the par­tic­u­lar case of the Invi­ta­tion­Ser­vice, it might indeed make sense to widen the tight inter­face we have today and work out a longer term solu­tion. But an approach like that is of course not fea­si­ble in most real world projects.

   Hon­estly — the more I think about it, the more I real­ize that “hacks” in gen­eral (i.e. not only in Alfresco envi­ron­ments) are actu­ally fairly com­mon. Truth is, that I am now exer­cis­ing all kinds of nasty Javascript while imple­ment­ing the new secu­rity requirements.

   In the end, I guess a big share of these prob­lems boils down to the nature of the tools we are given — the Java type sys­tem, acces­si­bil­ity mod­i­fiers (pri­vate, pack­age, final) and so on. For me, these tend to get in the way quite often. That is why I like “tools” such as dynam­i­cally typed lan­guages in cus­tomiza­tion projects.

   Maybe I’ll start a “best hacks” or “worst prac­tice” post series. ;)