Front End

[Guest]

I need just opionions. I'm VB.NET programmer and I work with another front
end HTML guy who doesn't know .Net and how to use the .Net controls. So far
he has been unwilling or unable to learn .Net even though I have been
training him, he hasn't caught on. He is good on "prettying up" the web pages
in old HTML controls and javascript, which anybody can do. He says its better
to do the front end first in HTML, then do the backend. By backend I mean
most of the major work to get the fields off the page and call components,
stored procs, Database Design, etc to do all the processing. The front end
would be defined as just the HTML and javascript. He thinks its better to do
the front end first using the old HTML controls, and then do the backend in
VB.Net. This to me is a bad choice, and I have been unable to convince my
boss otherwise. Maybe prototype it first in HTML, but my idea is to build the
system first, then "pretty" it up at the end.

What are the opinions out there from you experts for this little "Gem"? I
know this is unbeleivable that we are wasting time on a mission critical
project this way, but I need some other opionins because my boss trusts his
word, but not mine.

 

[Peter Morris [Droopy eyes software]]

Produce a very simple specification for maintaining a list of people + their
contact information (2 tables) and then have both of you start at the same
time. Presentation is unimportant, what is important is the functionality +
how long it takes to develop. Then assess the results based on readability
/ how long it takes to develop etc.

Sounds to me like one of you is going to leave for a new job

 

[Kevin Spencer]

Okay, so if I understand you correctly, your job is to design the
application and create the application code. His job is to design and create
the visual UI. So, once you have designed the business logic, you need to
work with him on the design of the UI. Then he can create the UI HTML in any
HTML editor, using placeholder HTML elements as "mock-ups" of the actual
Controls. These elements will simply serve as a visual aid for composing the
HTML of the page, and will be replaced later (by you). Once the HTML
interface layout is complete, he hands over the HTML to you. You paste the
HTML for each page into an ASPX page, replace the placeholder HTML with
Server Controls, and wire up the page to your business logic.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

 

[Guest]

So your trying to mix an old technology with the new one?!!! Thats strange.
Why not just use the new. Its faster, better and easier. Classic ASP is very
old, and microsoft decided to come out with a new easier platform that does
more. That is why microsoft decided to go a different route and changed the
platform completely. The advantages of .Net are enormous. All new classes are
created in .Net. No new classes (for example GDI+, LDAP security, Server
controls) are being created in classic ASP. None of these exist in classic
asp. When .Net first came out it had over three thousand classes. No telling
how many methods in these classes. And then there are properties. Of course
..Net replaced classic asp. The new model works more efficiently because it is
compiled code. The classic ASP model is just VB script. And this VB script is
exposed in the web site (for hackers to try and exploit), while the .Net
model is compiled binary code. No source code gets published to the server.
Also, the formatting of HTML is very easy. Everything is done in the
codebehind on the backend. The server controls now generate the html. Its a
lot easier. You don't have to do much HTML or javascript anymore, unless you
want to.

Of course you will be able to build faster in the new technology (assuming
that you are both at the same level).

Sounds like you have someone with a training issue. I can't imagine a web
guy who doesn't want to learn!!! His manager should send him to class, and
then after that if he doesn't know the new technology, there is a learning
issue on his part and appropriate action needs to be taken by the manager
to...

 

[Cowboy \(Gregory A. Beamer\)]

My guess is one of you will be leaving in the next six months.

You really have to get this guy to at least be willing to drop the proper
..NET controls on the page as part of his design. While there is nothing
wrong with creating a prototype in HTML, it is counter productive to lay an
entire site out in HTML and then force the backend developer to redo the
entire site, just so the HTML guy can feel like he was a success.

If your boss does not want to listen, keep track of all of the hours you
spend redoing work and then show him that. If he still does not listen,
write up exactly what you did to save the project and send it to his boss.
At the same time, put it in your resume and get a better job.

Yes, designers and developers can co-exist, but it requires compromise ON
BOTH SIDES. If this person is simply going to design, he should design and
then NEVER touch the damn app again. If it needs tweaks, he will HAVE TO
learn .NET.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside of the box!
*************************************************

 

[Registered User]

I need just opionions. I'm VB.NET programmer and I work with another front
end HTML guy who doesn't know .Net and how to use the .Net controls. So far
he has been unwilling or unable to learn .Net even though I have been
training him, he hasn't caught on.

Perhaps you aren't a very good tutor. I only tease because it is
probably not your job to train someone.

He is good on "prettying up" the web pages
in old HTML controls and javascript, which anybody can do. He says its better
to do the front end first in HTML, then do the backend. By backend I mean
most of the major work to get the fields off the page and call components,
stored procs, Database Design, etc to do all the processing. The front end
would be defined as just the HTML and javascript. He thinks its better to do
the front end first using the old HTML controls, and then do the backend in
VB.Net.

Huh? Has the phrase "all you have to do" been used?

This to me is a bad choice, and I have been unable to convince my
boss otherwise. Maybe prototype it first in HTML, but my idea is to build the
system first, then "pretty" it up at the end.

'Prototype' ha! All that will be prototyped is what the server spits
out port 80. You are correct.

What are the opinions out there from you experts for this little "Gem"? I
know this is unbeleivable that we are wasting time on a mission critical
project this way, but I need some other opionins because my boss trusts his
word, but not mine.

My opinion is you're pretty much screwed. The UI person's involvement
precludes using the tool properly. Still you might consider promoting
the many advantages ASP.NET brings to the table. You might find
localization to be a visible selling point.

If your company wants the website to be in both English and French how
can it be done? It might be as simple as creating a new resource file
or as complex as translating every page in the application before
creating a second website. After that what will it take to re-create
the website in Spanish?

regards and good luck
A.G.

 

[Paxton]

I don't see where the OP mentioned Classic ASP. And classic ASP is not
"just VBScript". It's a framework for building dynamic web
applications against which you can use VBscript, JScript or PerlScript.
Equally, the server side script is not "exposed on the web site".
It's processed on the web server and produces html to be output to the
browser.

 

[Eliyahu Goldin]

Well, being myself a programmer, I actually agree with the html guy. I
myself took this way several times. It is much easier to make a prototype in
pure html. It is not that difficult to convert html controls to server ones.
That is what runat="server" is all about. And anyway any user-friendly web
page would use a lot of javascript. So, if they guy writes good javascripts,
why not to let him do that? You may save a lot in your server-side code.