| Author |
 Topic  |
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
 Posted - 17 May 2006 : 11:41:59
|
| If you don't mind me asking, why do you think it needs converting to .Net |
 |
|
|
AnonJr
Moderator
United States
5765 Posts |
Posted - 17 May 2006 : 12:32:16
|
quote:
Originally posted by HuwR
If you don't mind me asking, why do you think it needs converting to .Net
Assuming the best of intentions, probably because Classic ASP is going the way of VB6... a long, slow, and painful death. I have a feeling that in the next 4-5 years my Classic ASP skills will be snickered at as much as my COBOL skills. (No offense to those of you who still use COBOL. Its just not as widely regarded as a "current" language.) |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 17 May 2006 : 15:08:55
|
Why convert it to .NET? Just cause...I want to . Really there is no reason that it has to be converted, I'm sure it will be run for many years as is. Yes I am looking to improve my coding skills. Another reason is that VS 2005 does not debug clasic asp like VS 2003 can. I would like to see the forum use the same language as the rest of my website ASP.NET using VB.NET which is the coding language I use at work. Also I would not have to convert a year's worth of data to use another forum software. Sorry...there are a few other reasons but I feel I am getting long winded here.
Just looking for a few other geeks possibly up for a challenge an exchange of knowledge.
I did find forum software based off of ASP.NET 2.0 today it looks pretty good and comparable to Snitz check it out if your interested http://www.dmgforums.com |
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 18 May 2006 : 17:43:11
|
It's just nice to have a different platform.
Plus, it's concievable that MS will drop support for ASP at a future date (far far future ;) ), and it might be best to be prepared for that contingency.
I did have a running plan for a conversion, but I ended up writing my own boards.
Doesn't follow the same scheme as Snitz so the databases are completely different.
I'm available mostly via email ( ghostnetworks [at] gmail.com ) or through one of my co-admins ( cassius.bilbao [at] gmail.com ).
We work together on a lot of projects, so when I'm busy, I share the workload with him.
A lot of the 1.1 API translates very well into 2.0, so I don't think there will be a big issue there with leaving backwards compatibility.
The concern I have is using an IDE to do all this.
A lot of devlopers still don't use VS and some don't have plans in the near future.
The other alternative is the Devloper Express editions for .Net (Web Devloper, C#, VB.Net, SQL Express etc...).
Even these can be a bit messy at first.
I might be a bit oldschool here, but instead of VS or VS Express, I'd suggest starting with a plain text editor and using base compilation with an included bat file.
The class files can be kept really, really simple. Which means the code will be easily accessible even to new programmers.
And namespace/class conflicts can be sorted out quickly just by using different sub folders.
The .Net built in membership and profiles features are still a little flaky.
I had to write an accounting software package and found this out the hard way.
For now, role based forms authentication seems the best at least until 2.1 or 2.2.
Now comes the Copyright information 
I think we can agree, that this too will be GPL, but what will the copyright read?
Will it allude to the original Snitz by name only, or will it include explicit copyright info.
E.G.
quote:
Original Snitz Forums and Database Copyright (c)
Michael Anderson, Pierre Gorissen, Huw Reddick and Richard Kinse
|
 |
|
|
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
Posted - 18 May 2006 : 18:12:07
|
| if it is based on the Snitz db schema it must include the full Snitz copyright as well as any of it's own since the database schema is copyright the same as the code |
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 18 May 2006 : 19:46:13
|
Then...
quote:
Snitz.Net Copyright (c) 2006 [Those involved]
Original Snitz Forums 2000 and Database Copyright (c) 2000-06
Michael Anderson, Pierre Gorissen, Huw Reddick and Richard Kinse
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
Come to think of it, I don't think we gave this project a name.
Snitz.Net? |
|
|
|
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
Posted - 18 May 2006 : 20:04:36
|
| you will have to check with Michael as to whether you can use the name Snitz, as he owns the trademark for the name, I'm sure that he will be fine with it though, but you should check anyway |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 19 May 2006 : 12:43:59
|
Here's some more thoughts to ponder and some more of my background detials.
1. Taking from my own experience as primarly a Windows developer and not that experienced with web programming. I was planning to use the IDE, I can write basic HTML with just a text editor but beyond that, I really rely on the debugging and intellisense features of the IDE. Having said that, I would say we should program this with the VS express edition, since everyone can download it for free. If we can pick the framework to use through the IDE then 1.1 is fine with me. The only thing I don't like about the IDE is that it is super buggy and MS has stated that it will not issue an update until Nov.
2. Database support? I'm not a big fan of Access for web site, I have worked on a site that uses an Access DB, what a pain. Setting permissions to get it work is not fun. My vote is for SQL Sever Express (again free) and MySQL. If some one really likes the access interface they could do linked tables and admin that way. MS has made the graphical interface available for SQL Server Express for free also.
3. Inline SQL vs Stored Procs: Stored procs please! as long as SQL Server and MySQL can run it. Otherwise inline is fine. I don't know a whole lot about MySQL but as far as I can tell we should be able to script them for both.
4. If it is not OK to use the Snitz name then in my opion there really isn't a point in converting it, there is other forum software that people can get for free that utilizes ASP.NET already. The pain is of course converting existing data to another forums data structure. That is kinda why I was wondering if the original developers were willing to contribute to the cause.
These opinions are subject to change according to which way the wind blows
|
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
Shaggy
Support Moderator
Ireland
6780 Posts |
Posted - 19 May 2006 : 12:51:30
|
quote:
Originally posted by kentk
Database support? I'm not a big fan of Access for web site, I have worked on a site that uses an Access DB, what a pain. Setting permissions to get it work is not fun. My vote is for SQL Sever Express (again free) and MySQL. If some one really likes the access interface they could do linked tables and admin that way. MS has made the graphical interface available for SQL Server Express for free also.
Remember, though, that most novices will come over all glassy-eyed when trying to get an *SQL database setup - Access is the easier option that a lot of people would already be familiar with and gives them a nice, easy entry point into dtabase driven web apps.quote:
If it is not OK to use the Snitz name then in my opion there really isn't a point in converting it
I wouldn't let that stop you; it sounds like an ambitious project that'll be a nice little challenge for those working on it and the finished product should, hopefully, help those other Snitzers who are finding .NET too daunting too dive into (e.g., me! ) get started with a whole new language.
|
 Search is your friend
“I was having a mildly paranoid day, mostly due to the
fact that the mad priest lady from over the river had
taken to nailing weasels to my front door again.” |
|
|
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
Posted - 19 May 2006 : 14:16:45
|
| why do .net programmers have this big thing about stored procedures, they are a total pain in the arse, offer very little if any benefit at all, and mean that most novice programmers have no idea what is going on, so I would suggest sticking to inline SQL it is much easier to edit, and will work on all DB platforms without any change |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 19 May 2006 : 16:29:52
|
From my perspective and my work experience stored procs have great benefits especially when it come to performance at least on MS platforms. Inline SQL in the .NET world is a pain in the******considering that you have to recompile before you can use the changes. HuwR your absolutely right about its benefit for multi platforms and I totally agree with that part of your arguement. But considering that Snitz currently only offically supports Access, Sql Server and MySQL all of which can use stored procs why would you not take even a small performance gain? Also I never said anything about ONLY using stored procs I'm sure there would need to be a mix of both.
We were all novices once in what we know, before I started using Snitz a little over a year ago and knew little to nothing about classic asp and I'm still at an intermediate level with web programming in general, but I just try stuff and figure it out or come to places like this and exchange knowledge.
I believe with the right amount of planning we can satisfy the majority of people who would consider upgrading to .NET and make it simple enough for those not so techy people to setup and use.
Since it was broguht it up, what other DB's other than the ones I mentioned above are people using with Snitz?
Great discussions!!! Thanks for participating. |
Kent
"Wakey, wakey, hands off snakey!" |
Edited by - kentk on 19 May 2006 16:30:46 |
|
|
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
Posted - 19 May 2006 : 16:47:00
|
quote:
stored procs have great benefits especially when it come to performance
Sorry, but that is total rubbish and one of those urban myths, stored procedures offer no performance benefits over a standard query |
|
|
|
-gary
Development Team Member
406 Posts |
Posted - 19 May 2006 : 17:44:20
|
| For a public release you'll shoot yourself in the foot using stored procs. It inhibits mod development and greatly increases the complexity and liklihood of failure for any updates in the future. That's not even touching backwards compatibility issues, the implementation differences between the various DB vendors and ease of debugging. |
KawiForums.com
 |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 20 May 2006 : 01:42:43
|
quote:
Sorry, but that is total rubbish and one of those urban myths, stored procedures offer no performance benefits over a standard query
Rubbish, ouch that hurts. Your probably right for 30 records that you might pull up you in a forum for a single topic you would not see a noticable performance gain, but for search queries and queries that are repeated over and over there is no way you could beat a stored proc. I've personally rewritten apps taking out the inline sql and put it into stored procs, just doing that took a process that my users did everyday from 2 hours down to 20 minutes. And this was done on an old network with way outdated computers and heavy network traffic.
Do you even understand how SQL Server works? Stored procs that are frequently used are complied and then left in the sql cache to be instantly accessed, where as inline code has to be complied by sql every time it is used. If it has not be used in a while it will be flushed from the cache. So the first time it is compiled it should performe on par with inline sql, but were it will really shine is the next 100 calls made to it.
Have you ever tested it? Just build yourself a small app with a database that has a decent number of records call an inline sql and then a stored proc, do this multiple times let us know what the results are.
Can you get the same performace benefit with Access, probably not, MySQL I can't answer that I have not had the pleasure of using MySQL yet. MS SQL Server, for sure, been there done that.
quote:
For a public release you'll shoot yourself in the foot using stored procs. It inhibits mod development and greatly increases the complexity and liklihood of failure for any updates in the future. That's not even touching backwards compatibility issues, the implementation differences between the various DB vendors and ease of debugging.
As I said in one of my earlier posts their would probably some queries that would need to stay inline, but I bet for the rest of them there is a common ground. Anybody making mods for it can chose however they want to do it. Don't get me wrong I do see your point and I'm definately not going to say it's stored procs or nothing. I would hope there would be open mindedness on boths side of the arguement.
In my last post I asked for DB being used other than Access, SQL Server and MySQL, still looking for responses on that, that would definately help in the decision making.
I can debug inline sql as easily as stored procs so I'm not sure how that plays in as a factor.
One idea I did have if the whole stored proc thing doen't fly is to
strip the inline code out of the asp pages and put it into an includes file and assign the sql string to a variable, that way it would at least be reusable, the way Snitz is written today you have to include that sql again every place you want to use it, hey what do you know another benefit of stored procs reusability.
Well I could just go on an on but then I would have nothing to say in my next post! |
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 20 May 2006 : 02:31:58
|
quote:
Originally posted by HuwR
quote:
stored procs have great benefits especially when it come to performance
Sorry, but that is total rubbish and one of those urban myths, stored procedures offer no performance benefits over a standard query
I have to agree there.
And, no, this is not the opinion of just a handful of people.
Kent, since you say your best work is behind an IDE, then we can still accomodate all parties.
There are code side triggers that can be added to guide the IDE during development
<Bindable(False), Category("Behavior"), DefaultValue("")> _
etc, etc...
I do this when I have to email a bit of code and I know the other guy is using an IDE.
This way, anyone else can still use a text editor.
As for Access DBs...
You have to understand, there will be people using this for intranet work, and installing SQL express may not seem worthwhile for them.
The best way to solve the DB issue is to build a DataAccess wrapper.
This way, each retrieval can be optimized for each DB.
MS SQL, Access, MySQL, maybe even PostgreSQL.
In fact, it may be best to do this from the start using n-Tier practices.
Data Access Layer for each DB. ( We can quarrel over StoredProcs later )
Business Logic Layer for all the core functionality.
And Presentation Layer so we can have different templates.
But for now, it may be best to use the Access DB so those participating can test the code on their own systems using Cassini or CassiniEX
After all, the DB schema will be pretty much the same for all platforms.
Until we can get permission, we can call the namespace "Beta".
So major sub namespaces can be :
Beta.DAL <-- Data Wrapper ( connect, get, update, insert, delete )
Beta.BLL <-- Core logic ( post, search, login, logout etc.. )
Beta.PL <-- Templates, custom user controls ( datagrids, repeaters, linkbuttons etc.. )
The namespaces can be easily changed to whatever we want later on.
We can add to the BLL a few modules like a URL rewrite, rss/atom, and thumbnail handler later on.
This way, we first get it to :
1) Read from the DB ( first step )
2) Do something ( few posts, debug, reorder forums, deubug again )
3) Finally the HTML in the form of the presentation layer. |
|
|
|
|
Topic |
|
|
|
Topic Locked
