Quando sviluppare in ASP.NET diventa frustrante

<< Persistere il ViewState sul database (o dove ci pare) | Home | BindingWrapper per classi che espongono solo fields pubblici >>

Quando sviluppare in ASP.NET diventa frustrante

Posted on mercoledì 28 giugno 2006 17.28

L'ultima volta che ho criticato un certo ambiente di sviluppo concorrente di Visual Studio c'è stata la chiamata alle armi. Vediamo un po' cosa accade questa volta, speriamo che la cosa passi inosservata

Devo fare una piccola web-app di tre pagine, sono vincolato ad utilizzare il suddetto ambiente e quindi ASP.NET 1.1 (perché manca tutt'ora il supporto alla più recente versione 2.0). Per emulare il funzionamento delle master pages, ho usato il solito (ed elementare) sistema dei due UserControl, un header ed un footer, che quindi per forza di cose arrivano ad avere al loro interno dei tag HTML che restano aperti.

Primo ostacolo: il nuovissimo IDE, rilasciato solo da qualche mese, non gradisce tali tag e quindi forzatamente li chiude ad ogni click sul pulsante "Save". Ho pistolato un po' sulle opzioni, cercato qualcosa su google, ma non ho trovato granché... Quindi tocca metterci mano con il Notepad. Va be'... lascio perdere, e proseguo (anche se un po' scocciato).

Il folder principale della mia applicazione ha una stupenda pagina dal fantomatico nome di Default.aspx. Creo un subfolder, faccio per creare una nuova pagina Default.aspx al suo interno e.... Ta-DA!! Errore dell'IDE, che solleva un'eccezione non gestita (con tanto di stack-trace) informandomi candidamente che esiste già nel progetto un file dal nome Default.aspx!!!! Incredibile!!

Chiosa finale: premesso che magari è colpa mia e che sicuramente il sottoscritto s'è perso qualche opzione per strada risolutiva di tutte le mie grane, ma, se così non fosse, avrebbe senso un supporto del genere? o è messo lì solo per dire: "ehy, con il nostro IDE puoi sviluppare anche su ASP.NET 1.1"? Ok... ora flagellatemi pure.

15 Comments Filed Under [ Misc ]

Comments

# Re: Quando sviluppare in ASP.NET diventa frustrante

Ma di che IDE stai parlando?

Left by Simone on 28/06/2006 17.43

# re: Quando sviluppare in ASP.NET diventa frustrante

Rincaro la dose: ha senso utilizzare quell'IDE (del quale questa volta non fai giustamente il nome) per sviluppare .NET?

IMHO No!

Può avere senso solo per portare applicazioni Win32 già sviluppate su piattaforma .NET... ed è comunque una bella fatica.

Left by Anonimo on 28/06/2006 17.48

# re: Quando sviluppare in ASP.NET diventa frustrante

Ciao Marco,
Ma lo User Control è uno User Control ASP.net?
Perchè che io sappia non si deve inserire un tag HTML in uno User Control. Gli user control sono pensati per essere inseriti in un tag FORM, il quale è contenuto ben all'interno del tag HTML... ma forse mi manca qualcosa...

Left by Davide Senatore on 28/06/2006 17.52

# re: Quando sviluppare in ASP.NET diventa frustrante

x Anonimo:
Boh... "giustamente non faccio il nome", francamente evito solo per evitare che la gente finisca qui per caso, perché né questa volta, né l'altra, mi sembra di aver detto chissà cosa, solo espresso un giudizio personale su un prodotto.

x Davide:
per tag HTML non intendo <HTML> ma un qualsiasi tag html, nel mio caso <DIV> :)

Left by Marco De Sanctis on 28/06/2006 17.58

# re: Quando sviluppare in ASP.NET diventa frustrante

Provato con gli update?

Andrea

Left by Andrea Raimondi on 28/06/2006 18.57

# re: Quando sviluppare in ASP.NET diventa frustrante

Purtroppo ho avuto la (s)fortuna di utilizzare l'IDE per un progetto Win32. Onestamente odio sia l'IDE che il linguaggio. (Io sono un purista Microsoft ;-))
Risultato: una media di 3/4 crash ogni 10 min.
Soluzione: disinstallato la versione 2006 e sono tornato alla versione 6.0.

Left by Marco Santoni on 28/06/2006 19.15

# re: Quando sviluppare in ASP.NET diventa frustrante

Mi ricorda stranamente qualcuno che giorni fà parlò degli anti-MS che non installano aggiornamenti ed SP... curioso vero?

Andrea

Left by Andrea Raimondi on 28/06/2006 19.20

# re: Quando sviluppare in ASP.NET diventa frustrante

Andrea, ascolta...
qua non si tratta di partigianeria. Si tratta di un prodotto che *non* funziona bene e non fa quello che dice di fare. Tutto qui. Sono onesto, ho installato solo l'update 1, domani provo a metter su anche la due e vi faccio sapere, perché spero di tornare trionfante dicendo di aver risolto il problema e credo sia un aspetto interessante anche per la community, visto che questa è UGIdotNET e non UGIVisualStudio. Sta di fatto che nelle release notes di Update2 non c'è il minimo cenno ai problemi che ho evidenziato e la cosa non mi fa ben sperare.

Ora che sono a mente fredda (e meno nervoso, perché in questi giorni al lavoro ho i minuti contati e francamente queste perdite di tempo mi danno veramente fastidio) analizzo meglio la questione.
1) capitolo tag che si chiudono... Qui i produttori dell'IDE sono stati veramente POCO FURBI (sostituire a caso con espressione equivalente): una delle maggiori lacune dell'editor HTML di VS2003, di cui s'era lamentato il mondo intero, era proprio l'invasività, il fatto che modificava il markup come voleva lui... santo cielo.. possibile che non venga in mente di sfruttare un minimo questo vantaggio di uscir dopo? Che senso ha partorire 'sta roba?? e se dovessi usare un repeater? in cui apro un tag <table> nell'headerTemplate e lo chiudo nel footerTemplate? domani devo controllare se fa storie anche così
2) capitolo Default.aspx che non può esistere in più di un folder... altra disattenzione M-A-D-O-R-N-A-L-E!!! Ma un cliente che compra questo prodotto per utilizzare ASP.NET, come deve fare dopo?!? deve rinominarsi tutte le pagine a mano? Possibile che nessuno abbia notato questo bug? Caspita... è una versione definitiva, mica una CTP! L'han provato prima di venderlo o no?!? Se penso che il team di VS2k5 è stato quasi crocifisso nei newsgroup per via di 5px di bordo nelle WebParts che erano hard-coded e non si potevano togliere, a questi cosa dovrebbero fare?

E poi mi venite a parlare di RAD, alla faccia del RAD... faccio 3 pagine e due user controls e già tocca impazzire con problematiche di questo tipo...

Mah...

un Crad perplesso...

Left by Marco De Sanctis on 28/06/2006 23.38

# re: Quando sviluppare in ASP.NET diventa frustrante

Per Gian Marco: Ho rimosso il tuo commento perché i termini che hai utilizzato forse erano un po' troppo "forti", spero che tu non te la prenda.

BTW, forse non hai seguito bene il discorso, ma non si parlava di VS2003 :)

A presto.

Left by Marco De Sanctis on 29/06/2006 9.20

# re: Quando sviluppare in ASP.NET diventa frustrante

Mi fà piacere vedere che non si puo' liberamente esprimere la propria opinione, complimenti. Quando puoi metti su un dizionario delle parole non forti così mi regolo.

Left by Gian Marco on 29/06/2006 12.48

# re: Quando sviluppare in ASP.NET diventa frustrante

Certo che puoi, magari rimanendo nei canoni dell'educazione evitando di dire che un certo prodotto è "un aborto".

Penso che essendo tra persone mature, non ci sia bisogno di alcun dizionario, basta solo un po' di buon senso, non ne convieni?

Ciao :)

Left by Marco De Sanctis on 29/06/2006 12.54

# Quando usare qualcosa che non si sa usare (e lamentarsene) ha poco senso... :-)

>>>>>>>>>>
L'ultima volta che ho criticato un certo ambiente di sviluppo concorrente di Visual Studio c'è stata la chiamata alle armi. Vediamo un po' cosa accade questa volta, speriamo che la cosa passi inosservata.
<<<<<<<<<<

Poi mi farai sapere che senso ha pubblicare un post sperando che passi inosservato... :-)

Voglio dire, lo scrivi nel Blocco Note e stai sicuro che nessuno lo legge.

Scherzi a parte, almeno per correttezza potevi citarlo, in fondo si tratta di un post di natura tecnica; chiaro che ciascuno scrive ciò che vuole nel proprio blog, ma io comincio a sospettare un po' che la tua non sia un'avversione, ma una vera e propria "fissa". :-)

>>>>>>>>>>
Devo fare una piccola web-app di tre pagine, sono vincolato ad utilizzare il suddetto ambiente e quindi ASP.NET 1.1 (perché manca tutt'ora il supporto alla più recente versione 2.0).
<<<<<<<<<<

Mi chiedo... perché non hai usato Visual Studio 2005?
A causa di quali vincoli?

>>>>>>>>>>
Per emulare il funzionamento delle master pages, ho usato il solito (ed elementare) sistema dei due UserControl, un header ed un footer, che quindi per forza di cose arrivano ad avere al loro interno dei tag HTML che restano aperti.
<<<<<<<<<<

Per emulare il funzionamento delle Master Pages, ci sono metodi ben migliori di quello che hai adottato.

Posso garantirlo per il semplice fatto che il 99,9% dei siti Web che ho sviluppato sono fatti con Delphi e ASP.NET.

Basta fare una ricerca mirata, anche perché si tratta di un'introduzione abbastanza recente (visto che VS 2005 è uscito in novembre ed esistevano già applicazioni Web che facevano uso di questi tipi di approccio).

Inoltre, va detto che le Master Page non sono una soluzione al "problema ereditarietà" delle pagine: sono solamente un espediente per ottenere un modello *grafico* di pagina (con alcune funzionalità correlate) nel quale ritagliare i contenuti di altre pagine, ma nel "code behind" le classi relative non hanno alcun legame particolare a livello gerarchico.

>>>>>>>>>>
Primo ostacolo: il nuovissimo IDE, rilasciato solo da qualche mese, non gradisce tali tag e quindi forzatamente li chiude ad ogni click sul pulsante "Save". Ho pistolato un po' sulle opzioni, cercato qualcosa su google, ma non ho trovato granché... Quindi tocca metterci mano con il Notepad. Va be'... lascio perdere, e proseguo (anche se un po' scocciato).
<<<<<<<<<<

E' un po' come scrivere codice sorgente con Word e lamentarsi del fatto che salva il testo con la formattazione.

Il problema non è nel "nuovissimo IDE", ma nell'uso della soluzione sbagliata al problema.

>>>>>>>>>>
Il folder principale della mia applicazione ha una stupenda pagina dal fantomatico nome di Default.aspx.
<<<<<<<<<<

Perché "fantomatico"? Mi piacciono le tue descrizioni tecniche perché, con certi aggettivi, riesci a far apparire strano e inaspettato qualsiasi comportamento che, in realtà, non nasconde nulla di esotico, anzi è del tutto normale. :-)

>>>>>>>>>>
Creo un subfolder, faccio per creare una nuova pagina Default.aspx al suo interno e.... Ta-DA!! Errore dell'IDE, che solleva un'eccezione non gestita (con tanto di stack-trace) informandomi candidamente che esiste già nel progetto un file dal nome Default.aspx!!!! Incredibile!!
<<<<<<<<<<

Non è incredibile, è solamente buffo (non da parte dell'ambiente).

Adoperi un tool di sviluppo e un linguaggio che non conosci e ti stupisci quando, facendo un'operazione illecita, l'ambiente ti risponde (per forza di cose) con un errore.

La spiegazione dell'errore in sé la inserisco di seguito.

>>>>>>>>>>
Chiosa finale: premesso che magari è colpa mia [...]
<<<<<<<<<<

Non è per essere pungente ma non posso fare altro che garantirti che *è* colpa tua. :-)

Il compilatore Delphi determina il namespace attraverso il nome attribuito alla unit; con la tua operazione, stai attribuendo a due unit lo stesso nome, cosa non ammessa nel linguaggio, oltre al fatto che avrai due classi con lo stesso nome all'interno del medesimo namespace.

Peraltro, almeno la mia versione di Delphi (che sospetto sia identica alla tua, però, benché tu mi faccia ogni tanto sospettare maliziosamente del contrario), non mi dice "Unexpected error from a strange and unidentified source", ma bensì "The project already contains a form or module named Default", e direi che è piuttosto indicativo del problema.

Lo "stack trace" può essere utile per andare a fondo nel problema, qualora l'errore fosse realmente inaspettato e non dovuto al programmatore, ma tu lo presenti come se l'apparizione dello "stack trace" sia riservata esclusivamente agli errori più astrusi e reconditi o dall'origine sconosciuta, oppure come se l'errore fosse più grave di quello che è in realtà.

Considerando che in questo caso l'errore è umano, ora sì che mi sembra il caso di usare il termine "sorvolare"... ;-)

>>>>>>>>>>
avrebbe senso un supporto del genere? o è messo lì solo per dire: "ehy, con il nostro IDE puoi sviluppare anche su ASP.NET 1.1"?
<<<<<<<<<<

Un supporto del genere ha senso in quanto, personalmente, lo utilizzo, e con molta soddisfazione (ma anche correttamente, requisito indispensabile).

Secondo me, ha meno senso, soprattutto da parte di una persona che si presume essere un professionista del campo, fornire pubblicamente le proprie recensioni di ambienti di sviluppo lamentando buchi laddove il prodotto segnala - comportandosi correttamente - quelli che sono esclusivamente errori umani, commessi per la mancata padronanza dello strumento e del linguaggio.

E' un po' come se un riparatore radioTV si stupisse di non riuscire a vedere immagini dal proprio Hi-Fi e, per questo, criticasse l'oggetto.

Dal mio punto di vista, se dovessi esprimere un giudizio tecnico di obiettività - per quanto poco possa interessare ciò che dico, ci mancherebbe - penso che la tua recensione assomigli di più ad una "crociata", peraltro condotta non particolarmente bene dato che si smentisce punto per punto in poco tempo.

Ammetterai che, in generale, quando ti capita di leggere le vicissitudini di inconsapevolezza nell'uso di un prodotto che vengono spacciate come difetti del prodotto stesso quando, usandolo quotidianamente, si conosce la natura dell'ostacolo e la relativa soluzione, un po' viene da sorridere... ;-)

Ciao,
Marco.

Left by Marco Breveglieri on 30/06/2006 15.30

# re: Quando sviluppare in ASP.NET diventa frustrante

Mamma mia che palle Marco... sinceramente...
La fissazione l'avrai te, cavoli. Non ho citato il nome del prodotto in oggetto semplicemente perché non mi va che gente che cerca info su Delphi in rete, finisca nei miei post-sfoghi che invece tanto tecnici magari non sono (ma sai com'è, uno nel suo blog ci scrive un po' quello che gli va di scrivere...). Tutto qua, mi sembra un modo di fare molto corretto e ben poco stigmatizzabile. Figurati che me frega che 50 di voialtri veniate qui a scrivermi di tutto, l'inizio era ironico.

Detto questo, cominciamo la trafila come l'altra maledettissima volta:
1) non mi frega dell'ereditarietà, non ho mai parlato di ereditarietà, so benissimo a cosa servono le MP (e tra l'altro nel mio caso sarebbero andate alla grande), ma mi pare che il mio puntiglio non fosse su quest'aspetto, bensì sul fatto che l'editor HTML di questo IDE E' INVASIVO, sul fatto che tanta gente si è in passato lamentata perché l'editor di VS2003 lo era e sul fatto che sarebbe furbo ogni tanto far tesoro anche dei feedback altrui... va meglio così? Che poi possa utilizzare notepad mi va benissimo, lo usavo anche con VS2003 (o meglio, disattivavo il designer e usavo l'editor XML), ma è così sbagliato attendersi qualcosa di meglio 3 anni dopo, anche se proviene da un'altro produttore?

2) Capitolo default.aspx... siamo alle solite... so benissimo che il problema è determinato dal nome duplicato, non sono nato ieri... ma possibile che debba essere costretto a cambiare MANUALMENTE il nome del file .pas in modo che la unit non abbia lo stesso nome di quella del folder principale? possibile che per creare una pagina in un subfolder debba affidarmi a dei workaround? c'è qualcosa alla base che non va, allora, perché evidentemente il supporto non è così buono.

Ah... ultima considerazione: non c'è scritto da nessuna parte che queste siano recensioni, mi pare... questo è un blog, non un magazine online, e se permetti lo gestisco come meglio credo e ci scrivo ciò che mi pare. E lo faccio con tutte le buone intenzioni di non riempirlo di boiate, credimi. Se tu invece non sei dello stesso avviso, francamente non ti posso far nulla. Sta di fatto che qui non c'è nessuna crociata in corso, e sta di fatto anche che i miei due punti tanto semplici da smentire, in realtà sono ancora lì che non son stati smentiti, forse perché nella foga di farlo non sei stato tanto attento al contenuto e non hai capito fino in fondo dove volevo andare a parare (come ho spiegato meglio in questo reply).

Con stima,

Marco

Left by Marco De Sanctis on 30/06/2006 15.57

# Risposte brevi e sciolte...

Marco Santoni scrive:
>>>>>>>>>>
Purtroppo ho avuto la (s)fortuna di utilizzare l'IDE per un progetto Win32. Onestamente odio sia l'IDE che il linguaggio. (Io sono un purista Microsoft ;-))
<<<<<<<<<<

Perché non lo hai fatto con Visual Studio 2005 il progetto Win32? :-)

>>>>>>>>>>
Risultato: una media di 3/4 crash ogni 10 min.
<<<<<<<<<<

Se hai catalogato come "crash" qualsiasi segnalazione derivante da un errore di utilizzo del linguaggio o del tool, come nel caso su cui si fonda l'intervento che stiamo commentando, allora non è l'ambiente ad avere problemi, oltre al fatto che D2006 è senz'altro più stabile di D6, ovviamente comparando la gamma di funzionalità degli ambienti (in D6 c'è meno di un quarto di ciò che è presente in D2006).

Se per questo, anche VS2005 e il compagno SourceSafe lavorano di fantasia a volte, ma non è sull'avvento di crash poco ripetibili che si può fondare un'analisi sensata, a meno che non siano intolleranti (come per qualcuno lo erano quelli di D2005, ad esempio, su cui un esame di coscienza è stato necessario, benché il prodotto fosse utilizzabile comunque, dato che mi sostenta ancora).

Anonimo (nome autorevole) scrive:
>>>>>>>>>>
Rincaro la dose: ha senso utilizzare quell'IDE (del quale questa volta non fai giustamente il nome) per sviluppare .NET?
<<<<<<<<<<

Rincaro ancora di più la dose: in certi casi, ha senso usare proprio .NET? Peccato che VS ti obblighi a farlo, a meno che non si rinunci al RAD.

>>>>>>>>>>
Può avere senso solo per portare applicazioni Win32 già sviluppate su piattaforma .NET... ed è comunque una bella fatica.
<<<<<<<<<<

Può avere senso per sviluppare applicazioni .NET senza dover imparare un linguaggio differente (non vi è alcun motivo per farlo) e passare ad una libreria più immatura e meno fornita (Windows Forms), che propone come novità componenti come il "BindingSource" (che in Delphi esiste, in forma del tutto similare, già dalla prima edizione del 1995).

Per quanto riguarda il porting alla piattaforma .NET di applicazioni esistenti, nella maggior parte dei casi non vi è di fatto alcun motivo per farlo (è stata Microsoft a decretare, tempo fa, "una macchina in ogni garage e .NET per ogni Windows", per fare poi marcia indietro).

L'importante in certi casi è avere la garanzia dell'esistenza di una strada, di un percorso di migrazione, che non deve essere necessariamente percorso per forzatura del produttore (si parla di Microsoft) ma deve costituire un'opportunità sfruttabile se le esigenze e requisiti del progetto lo richiedono.

Poi, supponendo che si voglia occupare più RAM per fare le stesse cose e quindi si pianifichi un porting verso .NET di un'applicazione VCL, mi piacerebbe sapere da quale esperienza deriva il giudizio "è una bella fatica", visto che nei casi che ho affrontato assomigliava di più ad una passeggiata, adatta anche a chi poco conosce gli "insight" dell'ambiente e del linguaggio (il package di componenti che usiamo in azienda si compila in duplice forma, Win32 e .NET, senza sforzi, con lo stesso sorgente). Provare per credere...

Marco De Sanctis scrive:
>>>>>>>>>>
[...] qua non si tratta di partigianeria.
Si tratta di un prodotto che *non* funziona bene e non fa quello che dice di fare.
<<<<<<<<<<

Sono disposto sulla fiducia a credere che non si tratti di "partigianeria", ma onestamente non credo ci sia nemmeno l'intenzione di risolvere effettivamente un problema, visto che al posto di una richiesta di aiuto su come affrontarlo viene, invece, perpetrata una serie di accuse basate sulla trasformazione di un errato uso dell'ambiente in bug dello stesso.

>>>>>>>>>>
perché spero di tornare trionfante dicendo di aver risolto il problema e credo sia un aspetto interessante anche per la community, visto che questa è UGIdotNET e non UGIVisualStudio.
<<<<<<<<<<

Nulla da dire sulla community (di cui peraltro ricevo piacevolmente anche la newsletter) anche se potreste tranquillamente cambiare il nome se tutti coloro che vi partecipano usano di fatto Visual Studio, oppure usano Delphi così come lo utilizzano coloro che hanno scritto qui. ;-)

Lo dico solamente perché se c'è l'intenzione di fare informazione anche su questo prodotto, pur se limitatamente in ambito .NET, quello che si sta facendo in realtà è pura disinformazione, visto che chi ne parla non ha né tempo né voglia di utilizzarlo o lo usa in modo improprio.

>>>>>>>>>>
capitolo tag che si chiudono... Qui i produttori dell'IDE sono stati veramente POCO FURBI [...]
<<<<<<<<<<
L'editor di Delphi, intanto, preserva molte delle caratteristiche del codice HTML sin dalla versione 8, a differenza di quanto avveniva con VS2003, con alcune integrazioni (supporto a HTML Tidy).

Io ho fatto una prova seguendo gli step, un po' abbozzati, che hai descritto, ma non ho ottengo alcun tag aperto (non vedo perché dovrebbe essere così), a meno che tu non abbia "spezzato" una tabella o qualcos'altro nei due controlli su cui hai basato la tua struttura di pagina, a cui io preferisco sempre e comunque una soluzione alternativa, analoga a quella adottata in alcuni portali degli "Starter Kit" di Microsoft: pagina ospitante, con controlli al suo interno. Io prediligo per la verità un'altra soluzione ancora, inglobata in un package, ma almeno quella appena menzionata è più soddisfacente e sensata, meno invasiva rispetto a quelli che sono i meccanismi di ASP.NET stesso, non di Delphi in modo specifico.

>>>>>>>>>>
capitolo Default.aspx che non può esistere in più di un folder... altra disattenzione M-A-D-O-R-N-A-L-E!!!
<<<<<<<<<<

Spero di aver spiegato abbastanza bene, nel messaggio precedente, che la disattenzione non è dell'ambiente, ma dello sviluppatore che non conosce il linguaggio Delphi e il significato attribuito ai moduli di codice sorgente (unit) nonché l'importanza del nome scelto e delle regole che vincolano l'uso di nomi.

La dimostrazione di questo sta nel fatto che se fai la stessa operazione con un'applicazione ASP.NET usando C#Builder, quindi basata sul linguaggio C#, non ti si presenta il medesimo errore (poiché il linguaggio e il compilatore non prevede convenzioni tra il nome del file e il nome della unit, un concetto assente).

La soluzione al problema, poi, è alquanto semplice: senza gridare allo scandalo e allarmarsi per una presunta necessità di rinominare tutte le pagine, è sufficiente attribuire un nome significativo alla unit .pas prima di rinominare il file aspx, il tutto dal Project Manager... era il caso di montare un caso istituzionale per una bazzeccola come questa? :-O

>>>>>>>>>>
E poi mi venite a parlare di RAD, alla faccia del RAD... faccio 3 pagine e due user controls e già tocca impazzire con problematiche di questo tipo...
<<<<<<<<<<

Non vengo a parlare di RAD a nessuno, ma ribadisco semplicemente quanto ho espresso nel commento precedente: è ridicolo prendersela con un martello pneumatico che non fa buchi nel muro se, alla fine, è il muratore che non sa come va usato correttamente. :-/

Ciao,
Marco.

Left by Marco Breveglieri on 30/06/2006 16.41

# re: Quando sviluppare in ASP.NET diventa frustrante

>>>>>>>>>>
Detto questo, cominciamo la trafila come l'altra maledettissima volta [...]
<<<<<<<<<<

Vabbè, se non ti interessa discuterne, basta dirlo.

Pensavo che commentare qualcosa fornendo opinioni tecniche, oltreché costruttivo, potesse essere anche d'aiuto (visto che dici di perderci del tempo e conosco il modo per risolvere); se così non è, lascio perdere subito. Basta intendersi...

>>>>>>>>>>
1) non mi frega dell'ereditarietà, non ho mai parlato di ereditarietà, so benissimo a cosa servono le MP [...]
<<<<<<<<<<

L'ereditarietà è una divagazione che mi è venuta in mente, in effetti, ma non c'entrava molto: era più che altro un'aspettativa personale sulle MP che poi si sono rivelate diverse da come mi aspettavo.

Appunto perché conosci le MP, dovresti almeno cercare di inseguire una soluzione che sia simile, e quella che hai adottato è la più scomoda e problematica fra tutte (secondo me).

Ce ne sono almeno due migliori in ASP.NET 1.1, e più somiglianti alle MP: l'uso di una pagina (che è il vero modello) in grado di caricare un controllo al suo interno, che costituisce invece il corpo della pagina stessa, oppure l'uso di una classe base per tutte le pagine che faccia riferimento ad uno UserControl che funge da "template", spostando tramite poche banali righe di codice i controlli visuali delle singole pagine (delle classi discendenti che le rappresentano) all'interno di un PlaceHolder.

Non è ben chiaro come siano fatti internamente gli UserControl che hai realizzato, ma si tratta di una soluzione problematica in quanto, ad esempio, non puoi spezzare tag mettendone una parte in uno e una parte nell'altro, come probabilmente hai fatto (non si evince dal messaggio, ma è a causa della mia incomprensione sul fatto che si trattasse di uno sfogo, piuttosto che di una discussione volta a trovare una soluzione adeguata, forse sono stati omessi volutamente questi particolari).

In tal caso, se questa è la condizione, non è un problema dell'IDE invasivo o della modifica al codice HTML (che è naturale, quando inserisci nuovi elementi usando il Designer ASP.NET), ma è un effetto collaterale derivante dall'uso di controlli aventi all'interno markup parziale che l'IDE, proprio per coadiuvare lo sviluppatore, tenta di chiudere autonomamente o considera errati con le confusioni che ne derivano.

Basta adottare una soluzione maggiormente "IDE friendly", come una di quelle elencate.

>>>>>>>>>>
ma è così sbagliato attendersi qualcosa di meglio 3 anni dopo, anche se proviene da un'altro produttore?
<<<<<<<<<<

Qualsiasi IDE, anche Visual Studio, si basa su convenzioni: non puoi fare tutto ciò che vuoi con i file che costituiscono i progetti, poiché vi sono degli automatismi che si aspettano di trovare le cose laddove le hanno messe.

Ripeto che, secondo me, è la soluzione scelta per simulare le Master Pages ad essere invasiva verso le funzionalità dell'IDE, non viceversa, oltre al fatto che in quel modo sei costretto a trascinare i due controlli (header e footer) in ciascuna pagina.

>>>>>>>>>>
Capitolo default.aspx... siamo alle solite... so benissimo che il problema è determinato dal nome duplicato, non sono nato ieri... [...]
ma possibile che debba essere costretto a cambiare MANUALMENTE il nome del file .pas in modo che la unit non abbia lo stesso nome di quella del folder principale?
<<<<<<<<<<

Qual è, secondo te, il modo con cui Delphi dovrebbe risolvere - in modo automatico - questo problema?

>>>>>>>>>>
possibile che per creare una pagina in un subfolder debba affidarmi a dei workaround?
<<<<<<<<<<

Non è affatto un workaround: le unit devono avere un nome differente tra loro, oltre al fatto che il nome predefinito attribuito da *qualsiasi tool* è poco significativo, quindi è da cambiare comunque; mi chiedo se sia così scandaloso attribuire un nome differente ad una unit rispetto al nome di file di una pagina, cosa che in Delphi faccio sempre, e sempre andrebbe fatto dato che da tale nome avviene poi il raggruppamento in namespace, quindi un nome significativo, che nello 0,05% dei casi coincide con quello della pagina, è opportuno.

In sostanza, tu cerchi un workaround per un problema che non è un problema vero e proprio ma una semplice diversità tra convenzioni prestabilite di due ambienti differenti. Non c'è molto altro da dire.

Comunque, non è in ogni caso un elemento "bloccante".

>>>>>>>>>>
[...] questo è un blog, non un magazine online, e se permetti lo gestisco come meglio credo e ci scrivo ciò che mi pare.
<<<<<<<<<<

Non mi sembra di aver mai detto il contrario, anzi.

Solo che, visto che si tratta di uno spazio pubblicamente accessibile, a volte mi viene da pensare (erroneamente) che il modulo per i commenti esista per consentire ad altri di esprimere opinioni. :-)

>>>>>>>>>>
Sta di fatto che qui non c'è nessuna crociata in corso, e sta di fatto anche che i miei due punti tanto semplici da smentire, in realtà sono ancora lì che non son stati smentiti, forse perché nella foga di farlo non sei stato tanto attento al contenuto e non hai capito fino in fondo dove volevo andare a parare (come ho spiegato meglio in questo reply).
<<<<<<<<<<

Non vedo molto contenuto filosofico, non mi pare che si tratti di argomenti religiosi, etici o morali.

L'unica cosa che vedo, personalmente, è una scelta che non adotterei mai nella simulazione di Master Pages, l'attribuzione all'ambiente di errori non imputabili all'ambiente stesso, la denuncia della necessità di un workaround non necessario (poiché, per chi utilizza proficuamente il linguaggio, non si pone semplicemente il problema, e in ogni caso non mi pare affatto "bloccante" come lo si dipinge), l'attribuzione di effetti collaterali al presunto revisionismo dell'IDE quando, in realtà, considerate le funzionalità del Designer, i problemi sono ben altri (non si può gestire correttamente, in quel modo, il markup di un controllo diviso in due file separati).

In conclusione, si dà secondo me all'ambiente di sviluppo tutta la colpa di problemi che, veramente, sono errate scelte progettuali e implementative. Nulla di più.

Per non replicare comunque la cosiddetta "maledettissima trafila" che ti farà perdere un sacco di tempo, non scrivo più, visto che dedicando anche molti caratteri il commento viene preso solamente come un "distratto" responso dato per pura foga.

Ciao,
Marco.

Left by Marco Breveglieri on 30/06/2006 17.21

Leave Your Comment

Title*
Name*
Email (never displayed): (will show your gravatar)
Url
Comment*
Please add 6 and 7 and type the answer here:

Crad's .NET Blog

L'UGIblog di Marco De Sanctis

Comments

Leave Your Comment

Preview Your Comment.