[Aspinfinity-developer] Render the page object

[Adullam <Se...@ad...>]

Hello all,
 
It dawned on me last night that we could be re-inventing the wheel
somewhat.  I had done a major amount of work on the page object concept
(by another name) already and we could use the abstract with David's
much more pure ASP Object Model.
 
There is already a semi removal of the render layer in the technology
known as CSS.  (also output as XML and using XML-Transforms is another
method (as used by OpenWiki)
 
In terms of objects we have the PAGE object the page object has a number
of blocked elements BLOCKS these blocks then have TEXT and IMAGES which
is as far as HTML goes.
 
Now the PAGE is the container for the BLOCKS and the BLOCKS are part of
modular applications or data stored in the blocks table (for example
custom HTML bits or a small ASP script the user_admin wants to add).
 
BLOCK come in two classes "normal" called BLOCKS and Special called
APPLICATION.  The normal called a BLOCK is stored in the database either
entirely or as a reference out to the applications file collection.
(This is demo'd in the pre-PoC example).
 
If we assume that the Page Object and the block object have no UI
information then they must be wrapped in something to stop them bleeding
and spilling all over the show.
 
So the PAGE object would need to refer to the User_Data and System_Data
area for details as to which THEME_PACK to use.  The PAGE object would
then load the first file AKA the PAGE_RENDER file (it need only be some
htm file with a few notes in it).  This file would contain lots of HTML
and a few TEMPLATE TAGS these items are were the different PAGE
SUB-OBJECTS i.e. BLOCKS will render. 
 
This use of a file while counter intuitive at first is actually very
liberating.  It allows the render layer to be set in any way a user
wishes and these settings can be shared.  If it helps think of the file
as an external data-source.
 
Now each BLOCK is rendered according to it's own settings and the
positioning in the PAGE_RENDER file.  But the blocks are equally devoid
of any real rendering data and so we load file #2 BLOCK_RENDER which
contains additional tags to show where in the HTML the BLOCK object
should be placed before all is placed into the PAGE that is being
rendered.
 
Hopefully you followed all that.
 
Now the PAGE object would respond to the following tags: (The content of
the first 4 are programmed from within the DATABASE [REGISTER])
 
<META_OBJECT> - This tag shows the PAGE object where the designer want
the meta data to go (along with additional CSS references and so forth)
<INFINITY_VERT> - This tag shows the PAGE object where the designer has
set aside space for banner adverts.
<INFINITY_THIN> - This tag shows the PAGE object where to place the page
wide "thin bar" if the designer has chosen to use it 
<INFINITY_FOOTER> - This tag shows the PAGE object where to place any
"footer" details
<LEFT_TOP>
<LEFT_LOW>
<MID_TOP>
<MID_LOW>
<RIGHT_TOP>
<RIGHT_LOW> - These tags position the block elements according to a
4-Col model that I'll explain in a sec.
<INFINITY_APPLICATION> -This tag shows the PAGE object where to place
the current selected application.
 
That seems to me to provide sufficient for any design the designer might
imagine and covers every know standard (and abuse of standards thereof)
known to web design.
 
Now for that 4-Col model.  On most websites you have 3 clearly definable
render areas top, middle (content) and bottom (Footer) 
The Middle is the area that occupies most space and often contains some
or all of: Left-side-bar | MIDDLE | Right-side-bar
It is this Left-Mid-Right model that I will focus on as it forms the
classic three column model of web design.  However I suggested that
ASP_INFINITY uses a 4-Col model.  This is achieved through use of the
database at render time and should result in a manageable render system.

 
Left and right cols are generally too narrow to bugger about with and
already allow the user to add a double column at ether side should they
(for some reason) wish to.
 
It is the Middle column that gets played with for there are three more
settings for the middle.  Mid-Left | MID | Mid-Right - if email lent
itself to graphics I'd have a go at drawing you a diagram but your
imagination will have to do.  The classic Mid object fills the entire
column width but the Mid-left and Mid-Right use only half the space.
With the correct use of CSS and DIV and HTML in the Theme the designer
should have allowed for the following:  when a Mid-Left and a Mid-Right
render one under the other they end up next to each other.  This is
standard HTML behaviour and therefore the PAGE RENDER CLASS can safely
ignore and be ignorant of any strange things designers and admins might
get up to.  This allows for a 4-Col layout and works reasonably well on
the websites I have seen that use this kind of model.
 
Objects can be set to render therefore in any of these FIVE locations [L
- ML - M - MR - R] in these two exiting levels [Up - Down] with these
two interesting switch values [Show - Don't Show] these are the controls
that are set on every block in the system.  These settings correlate
with the tags above and allow for such subtleties as objects that appear
above and objects that appear below the application.  These blocks also
carry a collection which lists the "pages" they should display on.
 
This brings me on to wrappers.
 
In the main all applications will load into the PAGE object and display
via the application tag point.  
 
HOWEVER, some applications will not be happy to do this especially if
they are complex.  Thus these applications are not loaded but wrappered.
This means they are modified so that they run directly from the
"Modules" folder but that they call a wrappering version of the PAGE
OBJECT once pre-Application and once post-Application which the
PAGE-RENDER will need to be able to deal with.
 
This is not as big a deal as it seems as the PAGE_RENDER file is linier
starting at the top and working down to the <INFINITY_APPLICATION> tag
which it stops at, returns control to the application and is called
again to process from after the Application is run.  Further more the
application needs to have a method of asking for the
DEFAULT_NEGATABLE_COL (DNC) to be left un-rendered.  This DNC is either
the left of the right in total which gives space for the application to
spread out (especially if it has it's own menu system that hasn't been
extracted into a BLOCK for some reason (like less object orient ports
might)).  The DNC should be a value set within the registry but should
be assumed to be right should there be no value set.
 
This although not pure like the original vision put forth by David has
the advantage of bridging the gap and allowing more applications to be
unified under the Infinity_asp application and common login.
 
Much of these ideas are demonstrated (with hard coding all over the
show) in the pre-PoC release and also at HYPERLINK
"http://kentindex.com/infinity"http://kentindex.com/infinity with the
use of OpenWiki as a semi plugged in item.  I am sure that using the
better class based system we can achieve far more powerful results than
this.
 
-Matt

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.6.0 - Release Date: 02/03/2005