Re: [Hypercontent-users] More functionality - will be help for all
Brought to you by:
alexvigdor
From: Alex V. <al...@bi...> - 2007-08-27 15:39:53
|
On Aug 27, 2007, at 12:38 AM, tom tom wrote: > Hi Alex, > > Pls find my observations below. > >> There is currently no mechanism for assigning a tag >> to multiple >> files, or for building based on that tag. > > Will this be in the road map? Because of this > limitatio n content editing is limited to the next > publish only. > People can't do edits for future publising cycles. One can make edits and either not save them (which leaves them in a persistent "draft" state), or save them and schedule the change of edition. So it is still possible to do edits for a future publishing cycle. The limitation of not having tags is more specifically that you cannot associate specific revisions of multiple files with one another for "snapshot" builds or batch scheduling operations. FYI, there are no institutions currently supporting HyperContent development with time or money, so there isn't a meaningful development roadmap. I volunteer my support to the community, but I cannot afford to volunteer significant development time - if you are sufficiently interested in improving HyperContent to fund development of particular features, we should discuss off-list. > >> The scheduling does work. The script that is there >> simply changes >> the "current edition" flag of the targeted file, so >> that the >> designated edition becomes active. > > Can you explain what is this SCHEDULING means in the > workflow screen, I am bit lost on that. Is it only for > one source file. What is the meaning of their entries. > What exactly it does as far as the publishing life > cycle, will it publish or build ...that file?, What is > it's functionality? The scheduling script is only for one source file. It schedules the change of the "edition pointer" that governs which version of a file is live. To have it republish immediately after updating the pointer, in schedule.xml you could add at line 23 after the SetCurrentEdition command <render path="${path}" destination="/publish/" force="false" delete="true"/> The schedule script has two times - a begin and end time. You might want to create a variant on the script to schedule just a single change of edition and immediately republish, something like this <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE workflow SYSTEM "http://hypercontent.sourceforge.net/dtd/ workflow.dtd"> <workflow binding="/**/*.*"> <event name="schedule-appearance" permissions="approve"> <input name="schedule-date" type="text" pattern="\d\d\d\d-\d\d-\d\d \d\d:\d\d" label="Please enter a date as YYYY-MM-DD [00-23]:[00-59]"/> <input name="schedule-edition" type="text" label="Please enter the edition to appear on the scheduled date"/> <variable name="scheduler" value="${actor}"/> <nq who="${scheduler}"/> <nq q="scheduled"/> </event> <q id="scheduled"> <event name="change-edition" when="${schedule-date}"> <exec command="org.hypercontent.workflow.command.SetCurrentEdition"> <with-param name="edition" value="${schedule-edition}"/> </exec> <render path="${path}" destination="/publish/" force="true" delete="false"/> <dq/> <dq who="${scheduler}"/> </event> <event name="cancel" who="${scheduler}"> <dq/> <dq who="${scheduler}"/> </event> </q> </workflow> > > What if I want all the content content to be > pulished/build on each monday. Can the publisher > define such a thing using the interfaces? You could define a workflow script to do this as well (5am every Monday): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE workflow SYSTEM "http://hypercontent.sourceforge.net/dtd/ workflow.dtd"> <workflow binding="/**/*.*"> <event name="schedule-publish" when="@0 5 2"> <render path="/" destination="/publish/" force="false" delete="true"/> </event> </workflow> > > We need a good explanation on HC scheduling facility, > in terms of what is the depth we can go etc. See http://hypercontent.sourceforge.net/help/project/workflow/ scheduling.html for syntax > >> Diff functions are not available currently. It may >> be possible to >> integrate an open-source diff library. > > Do you have any intentions to have it in future HC > versions. See my note above about the current lack of investment in HC. > > >> You do not have to have a single "approvers" group; >> you can create as >> many approver groups as you need as long as each has >> a unique name. >> You will need to create additional copies of the >> approval workflow >> configuration scripts for each content "area" and >> make a couple >> changes, e.g. >> >> ... >> <workflow binding="/scholarship/**/*.*"> >> ... >> <email who="group:scholarship-approvers" >> subject="[HyperContent]: >> Approval requested" content-type="text/html"> >> ... > > Yes this sounds good, but instead of forcing the HC > users to have different areas and have bindings can't > we do the following, > > We define seperate groups in the groups.xml, but when > the author who doesnt have the approval rights saves a > page it goes to the workflow screen, in this page > instead of having one link (Request for approval) > can't I have many links e.g > > Request for admissions approval > Request for scholarships approval > .... > ... > > When some one click on this it will generate the email > for the relevant group. Yes, you can do this. You would need to define each link as a separate event in approvals.xml: <event name="request-admissions-approval" who="${editor}"> <nq q="approval"/> <dq/> <email who="group:admissions-approvers" subject="[HyperContent]: Approval requested" content-type="text/html"> <![CDATA[ <h3>${editor} requests approval for <a href="${abs-server-base}${path}? mode=interactive&screen=workflow.approvals&work=${work-ticket}">$ {path}</a></h3> ]]> </email> </event> <event name="request-scholarships-approval" who="${editor}"> <nq q="approval"/> <dq/> <email who="group:scholarships-approvers" subject="[HyperContent]: Approval requested" content-type="text/html"> <![CDATA[ <h3>${editor} requests approval for <a href="${abs-server-base}${path}? mode=interactive&screen=workflow.approvals&work=${work-ticket}">$ {path}</a></h3> ]]> </email> </event> etc. > > > Other question is if a file goes through series > changes on many days, How can we save these partial > updates without being getting published, provided if > there is a sheduled publish. Cant we have flag to say, > this is only a partial update.? > The best way to do this currently is, after saving the changes, to go to the revisions screen and set the older revision to "current". You can then schedule the current pointer moving forward to the new edition using the schedule script. Cheers, Alex |