Adobe GoLive kontra Dreamweaver

Dreamweaver er den flest bruger og den du oftes vil støde ind i, og vil derfor nok være et naturilgt valgt  at lære den at kende...Umidelbart ville jeg dog sige du skulle tage det rene HTML kursus og lære den del fra bunden... HTML er trodsalt grundstenen i alt hvad man laver på nettet.....

95% procent herinde vil nok anbefale Dreamweaver frem for GoLive, og helt galt på den er de ikke.... det er det pogram flest bruge og du vil derfor let kunne finde support ol bla herinde. Dreamweaver har også DynamicContent (Database) som GoLive ikke har.... GoLive derimod har feks meget stærkt CSS del og en brugerflade der virker meget familiær hvis man er van til adobes pogrammer... At GoLive skulle skrive dårlig kode er en påstand man ofte ser, Jeg har dog aldrig set den bevist.... Det drejer sig om at kende og kune bruge det værktøj man vælger ordenligt...Både dreamweaver og Golive kan du download i en 30dages trailversion og prøve dem af og se hvad der passer dig bedst... begge har deres + og -
Adobe har lige købt dreamweaver så et stykke ude i fremtiden venter der måske en editor med det bedste fra hvert af pogramerne.....

Alt billedebehandling gør jeg i photoshop, de downloads der skal være er access filer og det ville være fedt med nogle online databaser i access, som kan bruges mens man er på siden. Hvis du forstår, hvad jeg forsøger at sige.....

PS. Jeg skal hilse fra Bjarke, kan det passe!~)

Har brugt begge programmer, men er mest forelsket i GoLive. Jeg er vant til at bruge Photoshop, InDesign og Illustrator og brugerfladen er klart den bedste hvis du er vant til Adobe produkter. Men jeg tror det er lidt en sag som ikke kan besvares for dig... du skal prøve det selv før du finder ud af hvad du bedst kan lide. Dog er database delen i Dreamweawer dejlig, og den kunne vi godt mangle lidt i GoLive =)

Jeg har lært at bruge begge programmer, men holder på Dreamweaver. Jeg synes brugerfladen er nemmere at finde ud af og så kan man f.eks. centrere en tabel, hvilket jeg ikke har kunnet i GoLive.

staz> "Dog er database delen i Dreamweawer dejlig". Jeg kender som ikke noget til nogen af programmerne eller andre editors, så hvad mener du...

Andre!~) Andet?~)

Du kan arbejder med databaser direkte i programmet, og det kan du ikke Golive =)

> Du kan arbejder med databaser direkte i programmet

Ikke helt rigtigt...der findes enkelte 3.parts løsninger....men de er ikke specielt gode...
Til database er DW helt klart bedst...
(Man kan evnt med lidt held finde en ældre GoLive....de havde DC, det røg vist først ud med 7eren så vidt jeg husker)

>og den kunne vi godt mangle lidt i GoLive =)

Kan være det kommer *S*...kan være de bliver til GoWeaver eller DreamLive ....

C",)

Database delen i Dreamweaver hvordan bruges den, er det ligesom access. Eller kan man indsætte en access database, så den kan bruges online.

<ole>

Hvis du ikke selv er en ørn til JavaScript og ønsker at bruge færdigsyede scripts i form af 'actions' (som de kaldes i GL) eller 'behaviors'/'extensions' (som de kaldes i DW), er der ingen tvivl: Brug DW ...!!!

GL's actions er komplet til grin - og kræver, der bliver udskrevet bunker af fuldstændig ligegyldig kode  :o|

/mvh
</bole>

>> GL's actions er komplet til grin - og kræver, der bliver udskrevet bunker af fuldstændig ligegyldig kode

Ja...hvis man glemmer at strippe sin kode før upload....så passer det ........ ;-)

Du har stadig din database (Mysql eller access), og den kan du hive elementer udfra direkte i dreamweawer =)

Men download dog de to programmer og oplev det selv. Det er klart den bedste vudering du kan få jo =)

Jeg vælger Dreamweaver, tak for alle de gode råd og den herlige lille debat!~)

Dreamweaver:
"Dreamweaver er den flest bruger og den du oftes vil støde ind i"
"vil derfor let kunne finde support"
"DynamicContent (Database)" (hvad det så end er...)
"database delen i Dreamweawer dejlig"
"Du kan arbejder med databaser direkte i programmet"
"Hvis du ikke selv er en ørn til JavaScript og ønsker at bruge færdigsyede scripts"
"Du har stadig din database (Mysql eller access), og den kan du hive elementer udfra direkte i dreamweawer"


Alle, der mener de har været en del af dette, smid et svar. Jeg uddeler points fredag over middag.....

!~)

Håber du bliver tilfreds =)

jesper >> "Ja...hvis man glemmer at strippe sin kode før upload....så passer det ........ ;-)"

Det kan da ikke være meningen, man skal betale en kvart sydfransk bondegård for et program, man skal gøre arbejdet for. Hvorfor skriver det dog ikke bare selv god kode i stedet for?

"Min gode mand - jeg forsikrer dem skam, at bilen fungerer fint ... de skal bare skubbe den"  ;D

Tak til alle også de som ikke smed et svar, men som vitterlig fortjente en del af kagen!~)

Ole
>>et program, man skal gøre arbejdet for.

Jamen det er heller ikke meningen at man skal....den funtion er der blot nogen der glemmer at bruge eller får den slået fra (enkele gør det med vilje)....... (nøjagtigt som Dreamweaver kan bruges forkert)

"Min gode mand - jeg forsikrer dem skam, at bilen fungerer fint ... de skal bare huske at fylde benzin på"  ;-)


Nu ville jeg egenligt ikke begynde en alt for lang diskution vedr. dette, selvom dette jo egenligt er stedet.
Men føler at jeg bør give lidt igen her. Detsvære er mine evner mht til at formulere mig på skrift ikke de bedste, men jeg kan da gøre et forsøg..
(Skal forsøge ikke at skrive en "GoLive: Hvad de skriftkloge ikke siger" artikkel.........*G*)

Tillad mig en del citater

"GoLive laver lange uforståelige koder "
Ja...det gør GoLiive... Og som adobe selv siger....disse koder vil med tiden blive enu længere og uforståelige
vilket i manges øre vel lyder fuldstændigt absurt... Men det er slet ikke så dumt når man kigger nærmere på det...
Måden hvorpå GoLive Og Dreamweaver håndtere deres Actions/extensions / behaviors/extensions er meget forskellige... Og det er i denne forskel forklaringen skal findes..Dreamweavers måde at  håndtre sine behaviors/xtensions kan i teknink sammenlignes lidt med en SSI model...Denne metode gør at koderne til disse kan holdes meget små..og er let tigængelige for brugeren mht. at ændre/rette/udvikle på disse...
GoLives metode er meget anderledes....Her er lidt hvad Golive selv sige
"Philosophy
The GoLive Action architecture is constructed with two goals in mind:
1 To give Web designers a collection of the most requested and most useful JavaScripts, flexible enough so that noncoders
and coders alike can produce a wide array of everyday applications with unparalleled ease of use.
2 To allow JavaScript developers to quickly and seamlessly integrate new functionality by writing their own code
and fitting it into pre-built blocks. By doing this, they can provide non-coding Web designers with the same flexibility
and ease of use found in standard GoLive Actions.
In order to achieve these goals, there needs to be more to GoLive’s Action handling than the simple, point-and-click
insertion of parameterized JavaScript code. To make sure that users can attach Actions to any kind of event handler
and allow the Actions to interact with each other, the Action mechanism needs to be able to check and track the
various Actions on the page.
In addition, the architecture also has to accommodate GoLive Action JavaScript developers. For them, the concept
has to be taken one step further: The Action execution mechanism needs to be free of possible dependencies. The
code must be generalized and made accessible, split into reusable modules and logical function blocks, thus allowing
for the so-called API, or Application Programmer’s Interface."
"Common misperceptions
1 "The size of proprietary GoLive HTML code is important." The proprietary code generated by GoLive software is
application-specific, and is used to maintain Actions and provide information for the Action Inspectors. It has
nothing to do with the main JavaScript code and can be easily stripped from published pages.
2 "To compare the code length of certain JavaScript functions, you should take the Action initialization and the
main loop into account." This is also incorrect. GoLive Actions use a framework so they can call each other, exchange
information, and be applied with a powerful flexibility. GoLive Actions can be triggered by many different event
handlers, and they also have the ability to call and interact with each other in complex ways. For example, using
GoLive Actions you can quickly construct sophisticated layer interactions that would take hours, if not days, to code
by hand.
3 "Hand-code is better." In certain cases, this is so, but for complex pages and large sophisticated sites, automatically
generated code allows for faster development and maintenance. It's important to remember that automatically
generated code was once hand-coded. What matters is the quality of the initial coding."
"Readability
GoLive is often criticized for writing code that is difficult to read and unusually large. Unfortunately, automatically
generated and maintained code is inherently difficult for human programmers to read. Though it is possible to keep
the amount of generated code to a minimum, it is impossible to completely avoid this problem.
GoLive’s automatic code generation and referencing architecture was designed with a focus on flexibility and
reusability. It uses a unique system of references to identify and execute each Action on a page. These references are
written into the Action initialization code and the object event handlers. Because of the high level of abstraction, it
is almost impossible to understand and follow this code.
However, when it comes to the JavaScript code found in the Framework and standard Actions, GoLive’s Action JavaScript
code is quite easy to read.
These issues will most probably not be addressed. It is even possible that readability will decrease in future releases in order
to achieve smaller Action code."
og det er her et af CowDog'ens kødben ligger begravet..
denne metode har selv. nogle bagdele...bla er det svært at ændre på Actions/extension på kode niveau... det betyder dog ikke at det ikke kan lade sig gøre...til dette bruges GoLive Actions Framework (SDK) og med den udvikles extension/actions osv til GoLive... (SDK er ikke for begynder *S* ).. Det er GoLives med drag&drop / Ponit&shot og palleter, Hvor GoLive holder styr på hvilket ting du bruger hvor og hvilket indstillinge disse har, der laver disse lange koder (som kan virke forvirende)...har man feks et billed som KUN bliver brugt af et script (ingen hanvisninger til billedet andre steder) og man ændre feks billedets navn.. så søger GoLive for at også scriptet rettes automatisk... Det er dette system der lave de lange ulæslige koder.  som egenligt ikke har noget med selv hjemmesiden at gøre, og derfor fjrenes, eller Bør fjernes ved opload..(og ja...her havde det været rart om adobe kunne finde en løsning der gjorde man slap fo at se på dem)
Vedr. størelsen af disse skriver adobe
"Size
As explained in earlier chapters, a certain amount of size overhead is unavoidable in graphical programming
environment like that of GoLive's Actions. But aside from that, many of the library functions and standard Actions
are written in an explanatory and readable format and can be optimized for code length.
This issue will most probably be addressed in a future maintenance release of the standard Actions and the GoLive Actions
Framework."
Man kan egenligt sige at Dreamweaver mht behaviors/actions er bygget til både at bruge, men også at let at kunne udvikle disse, hvor man i GoLive "blot" bruger disse...GoLive skal som alt andent værktøj bruges korekt... Gør man det vil feks script størelse blive reduceret med op til 50% ved opload
Jamen er slut resultatet af GoLives actions så overhovedet noget værd ???
"Browser compatibility
All standard Actions included with the application are tested across the current range of browsers and platforms and
their compatibility with them is indicated in the Action Inspector."
"Speed
When users take advantage of all available options, GoLive produces lean, fast-loading pages. Many of the standard
Actions provide excellent performance, while others offer good performance and maximum browser compatibility.
Degraded Action performance can result from several problems: pages that are not fully optimized, Actions that are
improperly used, or Action applications that are pushing the limits of JavaScript itself.
Performance of 3rd party Actions can differ widely and may be heavily dependent on how they have been implemented."
Man lavede en test med GoLive6 hvor man laved to helt ens sider, det eneste på siderne var roleoverscript, GoLive brugte sit "Smart Roleover" og på den anden side brugte man en af de mest udbredte metoder på nette kendt som "Lean Rollover"
"Smart Roleover" viste sig at bruge op til 23% mindre plads
Og lad det være sagt med det samme....der er INTET problem i at håndkode i GoLive...hverken HTML eller scripts.

Et andet stort emne hvor GoLive oftes mistolkes er Dynamic Content.... Det er rigtigt at DC ikke længere er en del af GoLive, men det betyder ikke at man ikke kan bruge det, Langt fra. GoLive valgte at satse på at lade sammarbejdspartnere udvikle pogrammer/extensions til dette.. Fordele og ulemper ved dette kan diskuteres, men det har helt klart haft en stor indvirkning på GoLives omdømme, og mange ønske det tilbage... Har man GoLive og ønsker DC vil jeg anbefale at kigge på http://www.zend.com/ (Som nogen Dreamweavere måske kender) Zend er adobes sammarbejdspartner Mht DC...

Jeg kunne begynde at remse op af de fordele jeg mener GoLive har, (Har nogen feks prøvet GoLive's SmallScren Rendering Solutions ?) ;-)  ... Men denne tråd skal ikke blive ALT for lang. så jeg vil slutte af med følgende udtalelse... helt på egen regning...

1. GoLive er Designeres værktøj... Dreamweaver er udviklerens/pogramørens værktøj.... brugt rigtigt (og evnt sammen) er de begge gode værktøjer.

2. Golive bliver ofte kritiseret for en del forskellige fejl som egenligt ikke er GoLives skyld. De fejl opstår pga brugerens manglende viden om det pogram han eller hun sider med... Man ser ofte en dårlig side lavett i Golive ... Betyder det så at GoLive bruger er dummere end andre ?...næppe...Hvor det går galt (Og en af de store forskelle på de to pogrammer) er den måde hvorpå man får pogrammet... Den typiske Dreamweaver bruger, har gået målrettet efter et pogram til at lave/udvikle hjemmesider, hvedkommende har ofte en medium til stor indsigt i emnet... Hvorimod mange kommer i kontakt med GoLive via et af Adobes andre produkter, da GoLive følger med i CS pakken... og det er her det går galt... GoLives brugerflade ligner meget adobes andre produckter, og dette kan let lokke folk til at tro at de "Bare" kan lave hjemmesider, men får de ikke sat sig ind i det de laver, bliver resultatet derefter...(Man måske kan påstå der %vis er flere "hobby"-brugere blandt GoLive)
Hvor mange af dem der har photoshop kan med rette siges at kende det værktøj på et niveau hvor de kan siges at bruge det profesionalt ??... At have værktøjet..og at kunne få det til at gøre nogenlunde hvad man vil have det til betyder langt fra man behesker sit værktøj..

Håber alt dette har været læseriet værd .... (Og måske åbne lidt op for oles stålsatte modvilje mod GoLive ;-P )

(Mine citater er fra Adobes (så vidt jeg ved, eneste) ofenentlige udtalese om disse emner "GoLive JavaScript Actions - White Paper"  http://www.adobe.com/products/golive/pdfs/gl_whtpr_js.pdf  )

Nåde ikke at skrive færdig *G*

Altså ikke at jeg ville skrive mere en det...*G*...men fik bare ikke nået at svare..*GGG*...
Men pyt.... Jeg solder dem aligevel bare op 

C,")

Jeg ved godt, vi ikke er enige om GL. Jeg bygger min mening om programmet på mine egne erfaringer med det - mine bekendte og kollegers ditto - samt de koder, jeg ser, der er skrevet i programmet.
De erfaringer stemmer slet ikke overens med din nærmest orgastisk, religiøse begejstring for programmet - og med al respekt, så lever jeg fint med den forskel. Jeg orker derfor ikke læse dine bibel-citater og personlige evangelier.

Det er ikke personligt ment, men når folk er _så_ ivrige for at overbevise mig om et bestemt produkts fortræffeligheder, kan jeg ikke få mig selv til at tage forsøget alvorligt.
Du oversælger i _den_ grad GoLive. Det virker på mig som religiøs forblændelse, for den eneste anden begrundelse, jeg kan få øje på er, at du skulle være på Adobe's lønningsliste - og dét tror jeg trods alt ikke  :)