RE: [Aspinfinity-developer] (no subject)

[David S. F. <ds...@cr...>]

Hi,
=20
I looked through the code of the project. It seems interesting and we
might be able to reuse some of the code, but I have a couple of
problems.
=20
Each page has to know and have hard coded way to much about its contents
to render.
Plus the components of the page are generated from template html/asp
like files, not objects.
There would be no easy way to customize the layout, you basically have
to put together each page from scratch.
=20
I do think the rendering object might be reusable if we were able to put
in object calls as opposed to file io operations.
And instead of passing file parameters, we can pass other parameters
that allows us to retrieve settings from a database.
=20
I'm actually pretty eager to start rolling with this project.
=20
Lets think from the perspective of an object on a page.
=20
=20
What does it need? (From a framework)

*=09
	Access to Authentication State
*=09
	Access to Debugging Methods
*=09
	The Ability to Retrieve Settings
*=09
	The Ability to Respond to Events (User Submits a Form, Clicks a
link, etc)

What does it have?

*=09
	Content

	*=09
		This could be one or more asp/html files that depend on
Authentication, Event State, Settings, etc

*=09
	Business Logic

	*=09
		This should control the flow of the application,
connecting Data to Content, Respond to Events, Retrieve Settings from
the Framework, etc
	*=09
		This should be contained within one class

*=09
	Data

	*=09
		This should simple abstract the backend data source so
that no db specific code is in the business logic layer
	*=09
		This should be contained within one class.=20

What am I missing.
=20
Any suggestions would be greatly appreciated.
=20
-Dave


  _____ =20

From: asp...@li...
[mailto:asp...@li...] On Behalf Of
Adullam
Sent: Saturday, February 26, 2005 4:14 PM
To: asp...@li...
Subject: RE: [Aspinfinity-developer] (no subject)


> layer one - Presentation Layer (If needed) - This would be inc or asp
files that have the actual HTML
What is the feeling on useing this?
=20
http://asptemplate.sourceforge.net/
=20
ASP Template is an ASP/ASPX templating engine whose main concern is to
separate actual code from HTML or any other presentation layer.

ASP Template currently sports lots of features:

*	Customizable markers for template objects=20
*	Nested templates=20
*	Common cycles like "for" blocks=20
*	Variables substitution with strings whose value comes from code
or from external files (includes)=20
*	Support for RegExp based substitution and home-made substitution
(for old IIS servers with scripting support prior to 5.5)

=20

	-----Original Message-----
	From: David San Filippo [mailto:ds...@cr...]=20
	Sent: 24 February 2005 16:34
	To: asp...@li...
	Subject: RE: [Aspinfinity-developer] (no subject)
=09
=09
	Hi,
	=20
	The framework should handle initiating a couple of singleton
like classes.
	The Authentication Class should be one of them. It should have
methods to check for things like "IsInGroup", "IsLoggedIn", IsAdmin, etc
	=20
	I think we should by design attempt to split each module, or
subsystem into three or four layers.
	=20
	layer one - Presentation Layer (If needed) - This would be inc
or asp files that have the actual HTML
	layer two - Business Logic Layer - The Actual Class File where
all the Business logic is stored
	layer three - DB Abstraction Layer - This is where the Data
Access is Abstracted, ( No Actual DB Connections in this) Uses layer
four differently depending on configuration options.
	layer four - Database Connectivity Layer - Where there is
actually DB Specific Code. This gives us flexibility in DB
implementation.
	=20
	Because VB Script doesn't support Inheritance I think some
classes will have to be implemented as subclasses.
	For instance we can have a low level ADO Wrapper that would be
implemented as a subclass in all data access classes.
	=20
	The idea is to isolate object calls into a limited set of files
as possible.
	=20
	What I would like to see, is a standard template/coding
conventions for building classes.
	This way they could all have the same look and field, comment
header, etc.
	=20
	Then perhaps we should list the responsibilities of each class
and agree on them before actually implementing them
	=20
	-Dave=20
	=20
  _____ =20

	From: asp...@li...
[mailto:asp...@li...] On Behalf Of
Adullam
	Sent: Tuesday, February 22, 2005 9:12 AM
	To: asp...@li...
	Subject: RE: [Aspinfinity-developer] (no subject)
=09
=09
	Hi
	=20
	I start the ball rolling on history and skills background. =20
	=20
	I am the managing director of an IT start-up, I have been
involved with computers on and off for my entire life but it has only
been the last four or five years that have seen the intensive study and
development.  My skills centre strongly around ASP / VBscript and
advanced ideas of data-relationships for which I have a nerdish
fascination.  I have also flirted with PHP and java and therefore am not
completely unaware of them although my skills stop as soon as there are
any major syntax differences from the languages I have used before. =20
	=20
	Many years ago I was quite the Turbo Pascal enthusiast.
	=20
	I have been hacking endlessly in ASP (and some PHP) over the
past years and see no real reason to stop working in ASP just yet.
Projects have tended to centre around information management and/or web
portals.  I have already created a basic system over the course of the
last two years but it is neither extensible nor portable.  I hope that
this project will one day replace the system I created/hacked-up.  This
was a substantial part of the final HNC year (HNC is Level 4 i.e. under
grad).
	=20
	It seems that so far we are in a broad agreement as to where we
are going next so if you do not mind I will cover a few points of jargon
that could cause difficulty if left unaddressed.
	=20
	+ First we have a core (PoC)=20
	+ Then we have the modular components of the core these modules
seem generally to be referred to as class subsystems but occasionally I
have found myself thing of them as core modules...
	+ Then we have Modules or Applications (Apps) which are the
things that will use the core to add functionality to the individual web
sites.
	=20
	I mention this now only so we can agree as to how to name them
as technically in a modular system most things can be called modules.
	=20
	I would also like to address quite quickly
	=20
=09
	=20
	User
	- An authentication/Security layer - It seems to me that the
"Authentication class" from before the PoC would handle this well with a
little further modification.
	- User data
	=20
	Technique
	- An Object Persistence Layer
	- A Data Access layer - how much this controls access to the DB
and how much this facilitates free access to the DB.  The fastest method
would be to allow direct SQL but this might not be the most secure.
Other issues are the idea of providing a simplification of access tot he
database so that the Applications can be DB blind and not worry about
platform.  Many sections might be entirely separated from the DB using
the preset "API" to access information that ultimately does come from
the DB.
	- etc - I am sure that a number of the items listed by Dave will
find there way here smartish as we start to plan.
	=20
	UI and display issues
	- A Module Rendering Object=20
	- A Page Rendering Object
	- A Skin Object for Skinning Pages
	=20
	I feel it is important to not be so pre-occupied with technical
perfection that we lose sight of the aims of the project.  I say this
mainly to myself as it is a personal bad habit of mine.
	=20
	In all I feel there are three issues that need to be addressed
and those are first "Technique" and then "Users" and "Output".  I feel
it would be a shocking miss-spending of our time if we went too far in
re-inventing the wheel and I'd like to know if anyone knows of any GNU
GPL/LGPL projects that could provide a source for us to use in meeting
certain aims (I'm thinking particularly of the Rendering portion of
Output).
	=20
	I feel that once these issues have been addressed matters of
finesse can be addressed such as XML usage, module/app installation and
uninstallation, upload management object, Smilie processor, standardised
anti-SQL-inject functions, first few apps/modules etc.
	=20
	One other point to consider is that the faster we arrive at
visuals the quicker we will garner support.
	=20
	-Matt
	=20

		-----Original Message-----
		From: David San Filippo [mailto:ds...@cr...]=20
		Sent: 21 February 2005 14:12
		To: asp...@li...
		Subject: RE: [Aspinfinity-developer] (no subject)
	=09
	=09
		Hi,
		=20
		In my opinion the next steps is to really discuss the
class subsystems that will support the core functionality for each
module.
		=20
		But before we get into that, I was hoping to get a
handle on the background/strengths weaknesses of the other developers
working on this project.
		=20
		I am an application developer who has been working full
time as a programmer for about 5 years. I live in New York City, am
looking to work on projects like this in my spare time, when my wife
isn't around. I am a Microsoft certified Application Developer (MCAD).
My strengths are in VB, VB.NET, classic asp, ASP.NET, C#, SQL, TSQL, etc

		=20
		Anyway, I also wanted to add some preface to the proof
of concept. As Matt indicated, there are no "dancing elephants." This is
proving that page rendering can be accomplished by dynamically
initiating objects based on database settings. It's really rough, but by
extending this concept we can create a fully functionally object
management system in asp. The end result is to package one base vbscript
class with asp html like forms to create a module. We can have the
framework auto wire to the class methods based on form settings. This
provides a consistent method for extending the core functionality any
which way we want.
		=20
		These are the kind of class subsystems that we will need
to work on, just off the top of my head.
		=20
		A Data Access layer.
		An authentication/Security layer.
		An Object Persistence Layer
		A Module Rendering Object
		A Page Rendering Object
		A Skin Object for Skinning Pages
		A Metadata Object
		A Configuration Layer (For Global Variables as
demonstrated in the POC)
		A Debug Object (As demonstrated in the POC)
		A File IO Object
		A XML IO Object
		A File Upload Object
	=09
		I haven't fully explored these ideas, I'm just throwing
them out there.
		=20
		Please let me know what you think.
		=20
		-Dave
		=20
  _____ =20

		From: asp...@li...
[mailto:asp...@li...] On Behalf Of
Adullam
		Sent: Monday, February 21, 2005 7:26 AM
		To: asp...@li...
		Subject: [Aspinfinity-developer] (no subject)
	=09
	=09
		Hi all,
		=20
		I have added the proof of concept to the releases on
sourceforge.
		=20
		I would like to consider the PoC as a starting point to
build our framework from.  However there are a number of issues to
address which I will outline below for feedback.
		=20
		Theme and UI: The core will need to allow for a seperate
set of files that in some way handle the look and feel seperate from the
data and logic layers.  The technique in the early trails centered
arround a module of functions and rendering subs.  This has some limits
but has the advantage of being tested and reasonably easy to document.
However there are other options and these include a templating system of
which there exists one for ASP under the GNU.
		=20
		Data Systems and Boot Strapping: In an ideal world the
set up of the system should be "upload files, naviagte to xyz.asp,
follow on screen promts." so the ideal of creating the connection to the
database from a file that the config creates is best.  This would mean
that we would be working DSN-less connection which has the advantage of
slightly lower server strain and given the nature of our object oriented
design I can see no benifit to using DSN. =20
		=20
		Where next: This is the key issue that we must address.
Although the above issues will have a bering on this issue it is vital
that we address it directly at least in terms of planning and general
direction.
		=20
		I have drafted a short list but am open to alternatives.
		=20
		Discussion of Proof of concept and surrounding ideas
		Documentation of best practice and options for UI-Layer
and the advantages and disadvantages of each technique
		Drafting of a list of requirements for the core
functions (and eventually creation thereof).  This would also include
the use of the authentication class with the core.
		Development of PoC into a core system
		First testing and feedback
		=20
		-Matt


	--
	No virus found in this incoming message.
	Checked by AVG Anti-Virus.
	Version: 7.0.300 / Virus Database: 266.4.0 - Release Date:
22/02/2005
=09


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.5.0 - Release Date: 25/02/2005