ERT 1.5

[Srirangan]

Bah.. <-- my response to Cd&'s "not so polite" post.

Can matt or cd& briefly describe the required custom solution? I'ld be more than happy to throw out a small prototype that fits the bill.

I have and will continue to contribute positively.. :-\

[nicholassolutions]

Well, what were you complaining about? What do you want changed and/or added? That should be what determines what you'd like to contribute....

I'm not totally sure what ERT should be. At the present, I guess it would be some small project like:

---
A collaborative environment in which to create new content, seamlessly integrated with a workflow/publishing software and discussion area ("forum") in which each thread may be automatically linked to any piece of content. All of this must be programmed securely using optimized OOP, must be SEF, and controlled by a single user management system with multiple access levels. It must also be 100% accessible, and skinnable, offering a variety of perfectly attractve skins that the users may choose from...oh, and don't forget the customizable, 100% reliable email notifs and RSS feeds for all content. It also needs a dash of "je ne sais quoi" just to top things off.
---

Now, in regard to Roy's "not so polite post." He was absolutely right -- if "Bah" is all anyone has to say in response, that just proves the point. I could not have made it clearer that people would have the freedom to make contributions of their choice on .net. The comments you and VGR made above were useless -- they identified no specific problem, and offered no solution or assistance. Both of you have passwords to the server (VGR at root level) and know where to go if you need resources to try out changes.  I appreciated your contribution to the Drupal Journal, but it sits there unfinished because I could not figure out how to make it do what we needed, and you did not follow through after the initial setup. I am not going to hound people to do stuff on here -- the motivation has to come from you. If the reason you didn't  finish that is because you couldn't, you didn't have time, or you worried that it would be a ton of work that the community wouldn't embrace in the end....join the club -- I've lost track of the number of mods and scripts I've written for ERT that are now sitting in the trash heap. That's just part of the game...

This is really just a matter of common sense. If someone is building something, and you walk by and say "Man, that sucks" and keep walking, he's likely going to feel like throwing his hammer at you, and rightly so. If your intention was to help, you would have done better to just keep quiet. If you expected him to say "oh really? How may I change it for you?" or "Oh really? Would you like to show me how to change it?" you need to get out a little more. If on the other hand, you say, "I have a suggestion -- it might be better if you did it this way, let me help" the guy is likely to hand you the hammer, and buy you a beer after work.

[Srirangan]

Read the rest of my post.......... :-/

[nicholassolutions]

I did read all your posts, and I appreciate your offer to help if you follow through on it. Cd& was not responding to that post, however, he was responding to this one:

I agree, I liked only the SMF part. Joomla, me not the biggest fan of.

(and VGR's similar one) which as I said above, is useless. Everyone here can agree that all avalable CMSs suck on one level or another. That doesn't get us any closer to a solution.

My description of what is needed, minus a couple small features, describes what we already have here. Whether you'd like to work on an updated, improved version of that, or try something completely different, I'll give you whatever you need to do it. I'd much rather make progress than bicker.

[COBOLdinosaur]

Well, I have actually been struggling to try and do a representative interface. The real problem is that there will not be a single interface; just a collection of widgets that act as containers for different types of content.  No fixed presetnation scheme; the user defines that.  No fixed sizes; the user will decide sizing and overlays of the widgets based on what they think is most important.  The same goes for position.  The user will have positioning control for just about everything except the title banner across the top and the footer with copyright and legal stuff.

comments = a widget for each or each group, ordered or filtered by the user. 
all comments by xxxx = a widget.
List of related topics = a widget.
list of attachments = a widget.
display area for an attachment = a widget.
White board = a widget.
comment editor = a widget.
external reference list = a widget.
navigation menu = a widget.
search options = a widget.
control panel = a widget.

What the hell is a widget?  A basic CSS rendering box, totally self contained with presentation 100% controlled by CSS through a basic stylesheet that gets overlaid with a user defined stylesheet generated and modified through a form based page.

The page layout is simple:

----------------------------------
|
| banner (static)         
|
|__________________________________
|
| content ( the user owns this area)
|
|
|__________________________________
|
| footer (static)
|
|____________________________________-

The user get total control of how they want the presentation done. The widget list above is by no means all that there is.  Anything that is appropriate for learning training and professional discussion is a valid widget.  The rendering box contains the structural HTML appropriate for the content the widget will hold.  Dynamics will be with scripted functions from libraries.  So development of a widget consists of writing the HTML with an id on everything; some general classes will emerge as we find common features in widgets.  Then if there are dynmaic controls necessary (layout management, AJAX, DHTML) the functions get written and added to the JS libraries after testing.

A widget should be testable on its own.  This is zero ego programming.  The developer gives up all control of presentation, page layout, and what they think is important.  The user owns the page.

So decide what widget you want to do and write it, without any concern about how it must react with the rest of the page.  Must be HTML4.01 strict compliant, light-weight, and flexible. 

I am still working on a sort of default wireframe for the user to start from, and I will posted it once i figure it out, along with some detail on the functionality required for some of the widgets like the whiteboard, that may be a little complex.

That is the front.  On the back everything will be database driven, and dynamically generated.  The db design is just about complete and centers around three primary entity modules:  Person, ContentItem, and Rules.  The processing model is a basic rules engine that processes the rules to generate a page.

The programming is not rocket science, but the method of presentation is radical and revolutionary.  Designers and developers will not like giving up control to the users.  Many users will not have a clue how to layout their page.  The critical piece is for us as developers to learn how build that control panel for the users so they can take control.

Cd&

[nicholassolutions]

That makes sense in the abstract....I would personally find a minimal example helpful.

[COBOLdinosaur]

A rough example (assume that variables will be resolved server side during generation:

<div id="commentsByWidget">
   <form id="CBWReadOnlyForm">
   <!-- Repeatable section -->
   <fieldset id="CBWMemberContainer1">
      <legend id="CBWMembername1">$membername</legend>
     <div id="CBWFields1">
       <input type="checkbox" value="$commentid">
      <span id="CBWDetail1">
         Forum: $forumname Related Article: $ContentItemTitle
      </span>
      <textarea rows="$userdefrows" cols="$userdefcols" id="CBWText1"
         value="$commentText"></textarea>
     </div>
   </fieldset>
   <!-- End repeatable area --- add as many iteration as required for all comments
   </form>
   <div id="CBWcontrols">
<!-- here go buttons, icons, or links to fire client side functions to create any number of effects.  Expand, collapse, hide, change cascade stacking order or change sort ordering; and AJAX function change to a different member, show comments for this forum only, show comments related to this article only removed checked comments, remove unchecked comments.  -->

   </div>
<!-- perhaps here a help icon, or an options button, or anything else that relates to the comments by widget -->
</div>

That is the easy part.  Now it needs default styling based on id.  It needs the javascript to implement the client side functions and AJAX interface.   
      
It will also need documentation for user styling options that can be incorporated into the user option screens and added to the rules database...  What CSS properties are available for each of the elements; what values are valid or invalid, and are there cross-browser issues that a user might need to be warned about. 

That leaves the server side scripting...  A CBW object with methods to apply the rules necessary to generate this widget; but before that object gets created and integratd, the widget itself is 100% testable by plugging in static values for the variables.  The AJAX function should be independent of any widget.  The AJAX objects get build and extended as they are required.


An anyone who wants to build a widget can so, test it, integrate it and get really irritated when someone craps on it without giving any kind of suggestion or real feedback except they don't like it.

Cd&