Need Help Using Dreamweaver AND Visual Studio.NET

[snorky]

We are a web shop currently standardized on Dreamweaver MX 2004 and ASP 3.0.
Currently, our graphics folks create each web site in Dreamweaver and put
placeholders in for dynamic stuff. Then our programmers manually (using
notepad) insert ASP (VBScript). This is usually a problem when the design
changes and the graphics people have to work their magic (and mess up the ASP
code in the process). We want to convert our ASP projects to ASP.net to take
advantage of code behind, form validation and lots of other stuff. It is my
understanding that we will need Visual Studio.NET to accomplish this. However,
giving up Dreamweaver is just not an option. We use its site-building features,
templates, stylesheets, etc. to create extremely flexible HTML that our
end-users can even maintain themselves. So I need to be able to let my graphic
folks continue to use Dreamweaver to build the visual portions of our web sites
and let our programmers use Visual Studio.net to take care of dynamic page
elements, database access, etc. In a perfect world these two groups could use
their chosen tools and pass the projects back and forth between the tools but
I'm not sure how to accomplish this. Is anyone doing this or do you know how
we can integrate these two tools for a complete solution? Many thanks in
advance.

[Brandon Taylor]

You won't have any problems doing your HTML/CSS in DW and then pulling it
into a VS project to do your .NET code. I do it every day. DW is hands-down
the best design tool out there, and is great for hand-coding VB Script, but
not so good at .NET. VS kicks the crap out of DW for code, but the design
tools flat out stink.

So, I use both to build apps until either Macromedia makes it's own version
of VS or Microsoft incorporates DW into VS. We'll just have to see!

Regards,
bT

"snorky" <webforumsuser@macromedia.com> wrote in message
news:d37ss7$fd9$1@forums.macromedia.com...

> We are a web shop currently standardized on Dreamweaver MX 2004 and ASP
> 3.0.
> Currently, our graphics folks create each web site in Dreamweaver and put
> placeholders in for dynamic stuff. Then our programmers manually (using
> notepad) insert ASP (VBScript). This is usually a problem when the design
> changes and the graphics people have to work their magic (and mess up the
> ASP
> code in the process). We want to convert our ASP projects to ASP.net to
> take
> advantage of code behind, form validation and lots of other stuff. It is
> my
> understanding that we will need Visual Studio.NET to accomplish this.
> However,
> giving up Dreamweaver is just not an option. We use its site-building
> features,
> templates, stylesheets, etc. to create extremely flexible HTML that our
> end-users can even maintain themselves. So I need to be able to let my
> graphic
> folks continue to use Dreamweaver to build the visual portions of our web
> sites
> and let our programmers use Visual Studio.net to take care of dynamic page
> elements, database access, etc. In a perfect world these two groups could
> use
> their chosen tools and pass the projects back and forth between the tools
> but
> I'm not sure how to accomplish this. Is anyone doing this or do you know
> how
> we can integrate these two tools for a complete solution? Many thanks in
> advance.
>

[snorky]

Originally posted by: Newsgroup User You won't have any problems doing your
HTML/CSS in DW and then pulling it into a VS project to do your .NET code. I
do it every day. DW is hands-down the best design tool out there, and is great
for hand-coding VB Script, but not so good at .NET. VS kicks the crap out of
DW for code, but the design tools flat out stink. So, I use both to build
apps until either Macromedia makes it's own version of VS or Microsoft
incorporates DW into VS. We'll just have to see! Regards, bT 'snorky'
<webforumsuser@macromedia.com> wrote in message
news:D37ss7$fd9$1@forums.macromedia.com... > We are a web shop currently
standardized on Dreamweaver MX 2004 and ASP > 3.0. > Currently, our graphics
folks create each web site in Dreamweaver and put > placeholders in for dynamic
stuff. Then our programmers manually (using > notepad) insert ASP (VBScript).
This is usually a problem when the design > changes and the graphics people
have to work their magic (and mess up the > ASP > code in the process). We
want to convert our ASP projects to ASP.net to > take > advantage of code
behind, form validation and lots of other stuff. It is > my > understanding
that we will need Visual Studio.NET to accomplish this. > However, > giving up
Dreamweaver is just not an option. We use its site-building > features, >
templates, stylesheets, etc. to create extremely flexible HTML that our >
end-users can even maintain themselves. So I need to be able to let my >
graphic > folks continue to use Dreamweaver to build the visual portions of our
web > sites > and let our programmers use Visual Studio.net to take care of
dynamic page > elements, database access, etc. In a perfect world these two
groups could > use > their chosen tools and pass the projects back and forth
between the tools > but > I'm not sure how to accomplish this. Is anyone
doing this or do you know > how > we can integrate these two tools for a
complete solution? Many thanks in > advance. > Thanks very much for the
reply. Do you ever have to go round-trip? That is, DW to VS.net, back to DW and
then back to VS.net, etc.? My concern is that stuff my designers do as well as
stuff my coders do will not survive during this round-trips. I understand how
this would work well for a single user but any ideas on how this works with
separate designers and coders?

[FSchmitthammer]

I also want to allow both designers and coders work on the same apps. Any steps on how to do this would be appreciated.

[Les Matthews]

Keep designers out of code-behind files (.aspx only).
Provide some instruction on being careful with the code and testing after
each incremental change to detect problems early and provide for easy
recovery.
Ensure that all modified files are thoroughly unit tested in the local site
before check-in.
Do all check-in/out with VS.Net, rather than DW.

"FSchmitthammer" <webforumsuser@macromedia.com> wrote in message
news:d3evvk$c80$1@forums.macromedia.com...

>I also want to allow both designers and coders work on the same apps. Any
>steps on how to do this would be appreciated.

[snorky]

Originally posted by: Newsgroup User Keep designers out of code-behind files
(.aspx only). Provide some instruction on being careful with the code and
testing after each incremental change to detect problems early and provide for
easy recovery. Ensure that all modified files are thoroughly unit tested in
the local site before check-in. Do all check-in/out with VS.Net, rather than
DW. so you're suggesting that everyone on our team, designers and coders
alike, must have VS even if they're only using it for check-in/out?

[Les Matthews]

That's how I do it. I'm sure you can develop a safe check-in/out process
without it - just make sure you involve a VS team rep when outlining the
process.

"snorky" <webforumsuser@macromedia.com> wrote in message
news:d3gslt$74t$1@forums.macromedia.com...

> Originally posted by: Newsgroup User Keep designers out of code-behind
> files
> (.aspx only). Provide some instruction on being careful with the code and
> testing after each incremental change to detect problems early and
> provide for
> easy recovery. Ensure that all modified files are thoroughly unit tested
> in
> the local site before check-in. Do all check-in/out with VS.Net, rather
> than
> DW. so you're suggesting that everyone on our team, designers and coders
> alike, must have VS even if they're only using it for check-in/out?
>

[Les Matthews]

The problem is if you check out only the .aspx and not the code-behind files
and you don't have VS, then you will not be able to compile in your local
working folder. The pages will likely error because you do not have all the
code, thereby, preventing you from testing your changes.

"Les Matthews" <LesAMatthews@yahoo.com> wrote in message
news:d3h0iq$chn$1@forums.macromedia.com...

> That's how I do it. I'm sure you can develop a safe check-in/out process
> without it - just make sure you involve a VS team rep when outlining the
> process.
>
> "snorky" <webforumsuser@macromedia.com> wrote in message
> news:d3gslt$74t$1@forums.macromedia.com...

>> Originally posted by: Newsgroup User Keep designers out of code-behind
>> files
>> (.aspx only). Provide some instruction on being careful with the code and
>> testing after each incremental change to detect problems early and
>> provide for
>> easy recovery. Ensure that all modified files are thoroughly unit tested
>> in
>> the local site before check-in. Do all check-in/out with VS.Net, rather
>> than
>> DW. so you're suggesting that everyone on our team, designers and coders
>> alike, must have VS even if they're only using it for check-in/out?
>>

>
>

[clintonG]

Someboday has it 'bass ackwards'

You do not want to keep the designers out of the code. You want to keep the
coders out of the design. The reason for this is because Visual Studio.NET
(VSN) is FUBAR and will mangle and delete the HTML source when the page is
opened in the so-called VSN 'Designer' and its been that way for the last
two releases.

It happens when coders open the page in the VSN Designer and then boom-boom
out go the lights when they leave the Designer or attempt to return to the
Designer.

So two copies of the presentation layer must be kept and managed. One which
is never given to coders preventing them from loading the file(s) in VSN and
the other redundant copy of files the coders can use and load within VSN2.

Microsoft guys speaking at events claim VSN 2005 does not mangle or delete
HTML source but then again they said that for what?

* FrontPage 97 (mangle and deleted source, Microsoft said "will be resolved
in next release")
* FrontPage 98 (proven lie)
* FrontPage 2000 (proven lie)
* FrontPage 2002 (proven lie)
* FrontPage 2003 (resolved)

--
<%= Clinton Gallagher
METROmilwaukee "Regional Information Services"
NET csgallagher AT metromilwaukee.com
URL [url]http://clintongallagher.metromilwaukee.com/[/url]



"Les Matthews" <LesAMatthews@yahoo.com> wrote in message
news:d3h3c8$ge4$1@forums.macromedia.com...

> The problem is if you check out only the .aspx and not the code-behind
> files
> and you don't have VS, then you will not be able to compile in your local
> working folder. The pages will likely error because you do not have all
> the
> code, thereby, preventing you from testing your changes.
>
> "Les Matthews" <LesAMatthews@yahoo.com> wrote in message
> news:d3h0iq$chn$1@forums.macromedia.com...

>> That's how I do it. I'm sure you can develop a safe check-in/out process
>> without it - just make sure you involve a VS team rep when outlining the
>> process.
>>
>> "snorky" <webforumsuser@macromedia.com> wrote in message
>> news:d3gslt$74t$1@forums.macromedia.com...

>>> Originally posted by: Newsgroup User Keep designers out of code-behind
>>> files
>>> (.aspx only). Provide some instruction on being careful with the code
>>> and
>>> testing after each incremental change to detect problems early and
>>> provide for
>>> easy recovery. Ensure that all modified files are thoroughly unit
>>> tested in
>>> the local site before check-in. Do all check-in/out with VS.Net, rather
>>> than
>>> DW. so you're suggesting that everyone on our team, designers and
>>> coders
>>> alike, must have VS even if they're only using it for check-in/out?
>>>

>>
>>

>
>

[Les Matthews]

"clintonG" <csgallagher@REMOVETHISTEXTmetromilwaukee.com> wrote in message
news:d3oqm9$lsi$1@forums.macromedia.com...

> Someboday has it 'bass ackwards'
>
> You do not want to keep the designers out of the code. You want to keep
> the coders out of the design. The reason for this is because Visual
> Studio.NET (VSN) is FUBAR and will mangle and delete the HTML source when
> the page is opened in the so-called VSN 'Designer' and its been that way
> for the last two releases.

Well, I guess you want both.

You can, however, prevent much of the VSN designer mangling by adjusting the
designer options. The default configuration provides for automatic
formatting when switching to design view or when saving a document - these
(and other related options) can be turned off though.