Menu
▾
▴
aspinfinity-developer — Developmental Mailing List
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(6) |
Mar
(10) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Adullam <Se...@ad...> - 2005-04-20 08:28:01
|
No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.18 - Release Date: 19/04/2005 |
|
From: Matt <mat...@ya...> - 2005-03-17 23:26:52
|
Hi, Nice idea, that sounds good [Claps] Talk more later (unwell). -Matt -----Original Message----- From: David San Filippo [mailto:ds...@cr...] Sent: 17 March 2005 22:08 To: Matt; ASP INFINITY MAILER Subject: RE: [Aspinfinity-developer] (no subject) Good Article. I didn't know vbscript classes supported properties (http://juicystudio.com/tutorial/asp/oaccess.asp) I actually want to create a simple module so you can see how I think things should be put together, and what the framework needs to be able to do. I was thinking a "List of Links" Module. It would have several modes View Mode which retrieves a list from a db and lists them. When granted Admin rights to the module, this mode would have edit links next to each link. Add Mode would be the interface for Adding Links. Edit Mode would have the interface for Editing/Deleting Links. Very Simple and show display the elegance of our approach. We will also start to see the things that will be the responsibility of the framework, and what will be left to the module in terms of responsibilities. -Ill let you know how it goes. -Dave -----Original Message----- From: asp...@li... [mailto:asp...@li...] On Behalf Of Matt Sent: Thursday, March 17, 2005 4:28 PM To: ASP INFINITY MAILER Subject: [Aspinfinity-developer] (no subject) While searching through the great and mighty WWW for an example of OOD for any members not total familiar with the idea I came across two rather yummy articles. First the tutorial/intro: http://juicystudio.com/tutorial/asp/classes.asp Now for those articles. They deal with uploading and calendar two things which may well need to become first level functions /apps that are available to developers from the beginning. This means creating API effectively to interact with the class level of things. I would like to challenge some people to create draft proposals of the examples given and work them into applications for the ASP infinity project despite the fact that infinity does not technically do anything yet. Where-ever a call is outside the scope of the app a note should be made of the requirement so that we create a form of road map towards a proper RC for Asp Infinity. This rises a few questions. If Calendar is an application then it must use the Database-Class however if it core tech exposing API for developers then should it interface directly with the DB? Where does pure Object design give way to speed and so forth. Further questions are raised which should be addressed and these include what is core and what is application? Where, if at all, do we draw the line? What data structure should an intrinsic calendar system use? should upload be a core function and what should it do (if anything) with it's data? What should the designated default folder be for such things and how does that effect the whole design? How should defaults be handled anyway? Now I've opened a can of debate up here are the two articles begging to become part of our project: http://www.asp101.com/articles/jacob/calendar/default.asp http://www.asp101.com/articles/jacob/scriptupload.asp -Matt A)bort, R)etry, I)nfluence with large hammer. PS. It seems that my system has refused to send this mail (I did wonder what had happened). I'm sending again now. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Aspinfinity-developer mailing list Asp...@li... https://lists.sourceforge.net/lists/listinfo/aspinfinity-developer -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005 |
|
From: David S. F. <ds...@cr...> - 2005-03-17 22:07:48
|
Good Article. I didn't know vbscript classes supported properties (http://juicystudio.com/tutorial/asp/oaccess.asp) I actually want to create a simple module so you can see how I think things should be put together, and what the framework needs to be able to do. I was thinking a "List of Links" Module.=20 It would have several modes View Mode which retrieves a list from a db and lists them.=20 When granted Admin rights to the module, this mode would have edit links next to each link. Add Mode would be the interface for Adding Links. Edit Mode would have the interface for Editing/Deleting Links. Very Simple and show display the elegance of our approach. We will also start to see the things that will be the responsibility of the framework, and what will be left to the module in terms of responsibilities. -Ill let you know how it goes. -Dave -----Original Message----- From: asp...@li... [mailto:asp...@li...] On Behalf Of Matt Sent: Thursday, March 17, 2005 4:28 PM To: ASP INFINITY MAILER Subject: [Aspinfinity-developer] (no subject) While searching through the great and mighty WWW for an example of OOD for any members not total familiar with the idea I came across two rather yummy articles. First the tutorial/intro: http://juicystudio.com/tutorial/asp/classes.asp Now for those articles. They deal with uploading and calendar two things which may well need to become first level functions /apps that are available to developers from the beginning. This means creating API effectively to interact with the class level of things. I would like to challenge some people to create draft proposals of the examples given and work them into applications for the ASP infinity project despite the fact that infinity does not technically do anything yet. Where-ever a call is outside the scope of the app a note should be made of the requirement so that we create a form of road map towards a proper RC for Asp Infinity. This rises a few questions. If Calendar is an application then it must use the Database-Class however if it core tech exposing API for developers then should it interface directly with the DB? Where does pure Object design give way to speed and so forth. Further questions are raised which should be addressed and these include what is core and what is application? Where, if at all, do we draw the line? What data structure should an intrinsic calendar system use? should upload be a core function and what should it do (if anything) with it's data? What should the designated default folder be for such things and how does that effect the whole design? How should defaults be handled anyway? Now I've opened a can of debate up here are the two articles begging to become part of our project: http://www.asp101.com/articles/jacob/calendar/default.asp http://www.asp101.com/articles/jacob/scriptupload.asp -Matt A)bort, R)etry, I)nfluence with large hammer. PS. It seems that my system has refused to send this mail (I did wonder what had happened). I'm sending again now. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick _______________________________________________ Aspinfinity-developer mailing list Asp...@li... https://lists.sourceforge.net/lists/listinfo/aspinfinity-developer |
|
From: Matt <mat...@ya...> - 2005-03-17 21:31:42
|
While searching through the great and mighty WWW for an example of OOD for any members not total familiar with the idea I came across two rather yummy articles. First the tutorial/intro: http://juicystudio.com/tutorial/asp/classes.asp Now for those articles. They deal with uploading and calendar two things which may well need to become first level functions /apps that are available to developers from the beginning. This means creating API effectively to interact with the class level of things. I would like to challenge some people to create draft proposals of the examples given and work them into applications for the ASP infinity project despite the fact that infinity does not technically do anything yet. Where-ever a call is outside the scope of the app a note should be made of the requirement so that we create a form of road map towards a proper RC for Asp Infinity. This rises a few questions. If Calendar is an application then it must use the Database-Class however if it core tech exposing API for developers then should it interface directly with the DB? Where does pure Object design give way to speed and so forth. Further questions are raised which should be addressed and these include what is core and what is application? Where, if at all, do we draw the line? What data structure should an intrinsic calendar system use? should upload be a core function and what should it do (if anything) with it's data? What should the designated default folder be for such things and how does that effect the whole design? How should defaults be handled anyway? Now I've opened a can of debate up here are the two articles begging to become part of our project: http://www.asp101.com/articles/jacob/calendar/default.asp http://www.asp101.com/articles/jacob/scriptupload.asp -Matt A)bort, R)etry, I)nfluence with large hammer. PS. It seems that my system has refused to send this mail (I did wonder what had happened). I'm sending again now. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005 |
|
From: Adullam <Se...@ad...> - 2005-03-14 23:34:58
|
No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 11/03/2005 |
|
From: David S. F. <ds...@cr...> - 2005-03-14 14:51:18
|
Sorry its been awhile, I've been busy on other things. I think Infinity.adf is my homesite project file. I still use Homesite 4.5 for hand coding asp files. =20 Couple of comments. =20 As far as header.asp goes, this was just a proof of concept that you can have each state of a module be stored as pure html in a separate file and the main class can include what it wants depending on the state. If your objection is the fact that it is a header, I agree, we are better server rendering the base layout, template/header/footer in its own class. =20 You added support for returning rows to cDBConnection. I was abstracting the Recordset handling in cDBDataReader. The usage was demonstrated in the BuildPage method of cPage. I was trying to mimic ADO.net and abstract the ADO specific code. Another advantage of abstracting the methods, is that any major changes only need to be made in one file =20 I am kind of against API.asp. At the very least they should be contained within a class as that should be a goal of the design. I see no reason they need to be standalone. =20 cConfiguration is not live in memory and that's the beauty of it. It is a class and will only come into memory when initialized. Afterward it goes out of memory. If we do make it lookup values from a DB or properly structured XML file, it only need lookup and store values for that particular page. =20 I'm not sure what your point about the Connection String was. I do know we need to abstract the DB from each module, but that's a TBD item. =20 What in the engine are you looking to complete or design. When you say engine, do you mean the rendering engine, what loads and maintains each module instance.=20 =20 -David |
|
From: Adullam <Se...@ad...> - 2005-03-14 10:08:25
|
No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 11/03/2005 |
|
From: Adullam <Se...@ad...> - 2005-03-11 21:59:23
|
No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.1 - Release Date: 09/03/2005 |
|
From: Adullam <Se...@ad...> - 2005-03-04 11:52:21
|
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 |
|
From: David S. F. <ds...@cr...> - 2005-03-03 14:02:58
|
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 |
|
From: Adullam <Se...@ad...> - 2005-03-03 00:27:43
|
No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.5.7 - Release Date: 01/03/2005 |
|
From: Adullam <Se...@ad...> - 2005-02-26 21:13:37
|
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 |
|
From: David S. F. <ds...@cr...> - 2005-02-24 16:34:10
|
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) 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 =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 =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 |
|
From: Adullam <Se...@ad...> - 2005-02-22 14:12:21
|
Hi I start the ball rolling on history and skills background. 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. Many years ago I was quite the Turbo Pascal enthusiast. 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). 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. + First we have a core (PoC) + 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. 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. I would also like to address quite quickly 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 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. UI and display issues - A Module Rendering Object - A Page Rendering Object - A Skin Object for Skinning Pages 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. 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). 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. One other point to consider is that the faster we arrive at visuals the quicker we will garner support. -Matt -----Original Message----- From: David San Filippo [mailto:ds...@cr...] Sent: 21 February 2005 14:12 To: asp...@li... Subject: RE: [Aspinfinity-developer] (no subject) Hi, In my opinion the next steps is to really discuss the class subsystems that will support the core functionality for each module. 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. 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 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. These are the kind of class subsystems that we will need to work on, just off the top of my head. 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 I haven't fully explored these ideas, I'm just throwing them out there. Please let me know what you think. -Dave _____ 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) Hi all, I have added the proof of concept to the releases on sourceforge. 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. 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. 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. 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. I have drafted a short list but am open to alternatives. 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 -Matt |
|
From: David S. F. <ds...@cr...> - 2005-02-21 14:11:45
|
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 =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 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) 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 |
|
From: Adullam <Se...@ad...> - 2005-02-21 12:26:31
|
Hi all, I have added the proof of concept to the releases on sourceforge. 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. 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. 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. 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. I have drafted a short list but am open to alternatives. 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 -Matt |
|
From: Matt <mat...@ya...> - 2005-02-06 19:00:17
|
Hi all, I've been asking everyone to sign-up to the ASP Infinity mailer so that work can be more co-ordinated and all ideas are recorded for our own future reference. Currently on the cards is a proof of concept from Dave that I hope to play with Monday and then post for all to see. Regards Matt |
