Ask Questions and Find Answers

@1: Yes, that would be a possibility. One requirement for these pages is that some fragments must be there/must not be removed.
@2: Yes. List the pages and(!) access the fields of the page. Pages are indeed assets? Ha. I guess, I thought otherwise that because they are not in the search index.

@Challenge part:
Well, I don't think that a structure is needed. It would just require two things: A name for each fragment and to enforce that a few fragments can't be removed. Maybe the editors could move them around, but they shouldn't be able to delete them.

Since each fragment is named and each lfr-editable has an ID, the field can be found/accessed:

Field field = page.getField(fragmentName, editableId);

Two other useful methods would be:
List<Field> fields =  page.getEditableFields(editableId)
List<Field> fields = page.getFragmentFields(fragmentName)

Note: The developer can't set the fragmentName, since the fragment is added multiple times.
Note 2: The developer of the PDT would of course need to know the fragment names, but he currently also needs to know the structure field names.
Note 3: It should be possible to "know" the fragment name in the template, to use it e.g. as part of an id and a javascript selector.

<div id="${fragmentName}_something">


The whole thing could also be processed by acessing the xml, but looking at webcontent and the necessity to sometimes parse/write the xml, I'd rather not do that again. The xml probably should stay available, but it really should be discouraged to use it.

We always found the Calender highly inadequate for Events. Business users use mostly Outlook and expect that the Calendar is syncroniced. Also, Events often need alot of text, there should be images or videos, ...

So we use Webcontent. We display the next view events in a list, we even have a small month overview(days of the month) at a customer where all days with relevant events are highlighted (and clickable, of course). It is not ideal, but we found it better than using Calendar.


The ability to create our own page types was actually part of the idea to have Marketing Pages and Contact Pages and ... I was just using events as an example. And I prefer a generic solution to a special solution just for events.