Ξεχνάς ότι το ίδιο το SharePoint είναι "no code, no xslt" και περίπου σαν Access ... ή θα ήθελε να είναι. Αντί να γράφεις data access κώδικα και ASPX σελίδες σου φτιάχνει "αυτόματα" τη φόρμα ενώ με τον SharePoint Designer μπορείς να αλλάξεις το layout της φόρμας "χωρίς κώδικα και XSLT" αλλά ...
Η διαφορά μεταξύ του ίδιου του SharePoint και όλων των (άπειρων πλέον) Silverlight form designers είναι ότι το SharePoint προσπαθεί να υλοποιήσει το "no code" χρησιμοποιώντας τα advanced features του ASP.NET 2.0 (π.χ. templating, validators) ενώ οι SL form designers το κάνουν αυτό χρησιμοποιώντας τα features του Silverlight τα οποία είναι αρκετά πιο εύκολα στο visual customization. Ένας λόγος γι αυτό είναι ότι στο Silverlight η χρήση των MVοτιδήποτε patterns είναι σχεδόν δεδομένη, ενώ το ίδιο το SharePoint σχεδιάστηκε στην εποχή των WebForms και έτσι δεν παρέχει εύκολο διαχωρισμό μεταξύ δεδομένων και παρουσίασης. Η ομάδα του SharePoint προτίμησε να φτιάξει τις δικές της διαλέκτους XML για να ορίσει το σχήμα των λιστών και των πεδίων αλλά κάπου τα πράγματα μπλέχτηκαν πολύ περισσότερο απ' ότι χρειαζόταν. Από την άλλη, το templating είναι από τα πιο advanced features του ASP.NET και ο τρόπος με τον οποίο χρησιμοποιείται στο SharePoint σπάνια συναντάται σε web sites.
Όσα λες ισχύουν ήδη για το SharePoint το ίδιο. Το ίδιο το SharePoint είναι παγίδα γιατί κάνει τον developer/administrator/end-user να νομίζει ότι όλα είναι εύκολα και γρήγορα μέχρι να χρειαστεί το "κάτι παραπάνω". Όταν φτάσεις σε αυτό το σημείο, αρχίζει το "βαρύ customization". Είτε μιλάμε για SharePoint είτε για Silverlight έρχεται μία στιγμή (και μάλιστα πολύ γρήγορα) που η απλή generated φόρμα δεν αρκεί. Το SharePoint σου επιτρέπει να προχωρήσεις με templates και server-side XSLT. Οι Silverlight designers .... ο καθένας με ότι φαντάζεται. Και στις δύο περιπτώσεις όμως η δουλειά που απαιτείται αυξάνεται κατακόρυφα.
Τέλος, μην ξεχνάς ότι το SharePoint επιτρέπει (ή θα ήθελε να επιτρέπει) στους end users να φτιάχνουν τις λίστες και τις φόρμες τους χωρίς κώδικα. Ο χρήστης (ή ο SP administrator) δεν νοιάζεται για το τί τεχνολογία χρησιμοποιείται από κάτω, τη δουλειά του θέλει να κάνει και μάλιστα μέσα σε λίγες το πολύ ώρες. Αυτός δεν θα νοιαστεί αν o Silverlight designer "κλέβει" και δεν είναι καθαρή HTML.
Εκεί που μπορεί να δημιουργήσει πρόβλημα ο SL form designer είναι ότι μπορεί να κάνει τον end user να νομίσει ότι μπορεί να πετάξει χύμα πεδία μέσα στις λίστες χωρίς να σκεφτεί θέματα security, views, versioning κλπ με αποτέλεσμα να καταλήξει σε μία λίστα-μπάχαλο, η οποία μπορεί να παίζει ωραία μέσα στον designer, είναι όμως 98% unmaintainable και ορθάνοιχτη σε όποιον ξέρει ελάχιστη javascript.
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos