Εφαρμογή Master / Λεπτομέρεια σχέσεις χρησιμοποιώντας προσαρμοσμένες λίστες

Οι χρήστες του φόρουμ συχνά ως ερωτήσεις όπως αυτό:

> Γεια σου,
>
> Παρακαλώ να μου πείτε αν υπάρχουν οποιεσδήποτε δυνατότητες να οικοδομήσουμε μια προσαρμοσμένη λίστα με
> Master και λεπτομέρεια τύπου (όπως τιμολόγια) χωρίς χρησιμοποίηση InfoPath.
>

SharePoint παρέχει μερικά από τα χαρακτηριστικά γνωρίσματα box που υποστηρίζουν τα είδη των επιχειρηματικών απαιτήσεων, όπως αυτό.

Σε γενικές γραμμές, συνδέει δύο λίστες, μαζί με μια στήλη αναζήτησης. Λίστα A περιέχει τις πληροφορίες κεφαλίδας τιμολόγιο και καταλόγου Β Τιμολ.

Χρήση επιπλέον λίστες να διατηρήσει τον αριθμό των πελατών, αριθμούς προϊόντος, κλπ.

Χρησιμοποιείται το τμήμα web ερωτήματος περιεχομένου (σε ΒΡΎΑ μόνο) ή/και δεδομένα μια δείτε τμήμα web για να δημιουργήσετε συγχωνευμένες προβολές των λιστών. SQL Server υπηρεσίες αναφοράς (SRS) είναι επίσης διαθέσιμα για την αναφορά πλευρά της.

Ωστόσο, Υπάρχουν κάποιες σημαντικές περιορισμούς που θα καθιστούν δύσκολη τη χρήση καθαρής out-of-the-box χαρακτηριστικά για τίποτα που είναι μάλιστα και μετρίως πολύπλοκες. Αυτές περιλαμβάνουν:

  • Μέγεθος της αναζήτησης σχετικές λίστες vs. "εξυπνάδα" η στήλη τύπου "Αναζήτηση". Ένας τύπος στήλη αναζήτησης παρουσιάζεται στο UI διαφορετικά ανάλογα με το αν έχετε ενεργοποιήσει πολλαπλή επιλογή ή όχι. Σε κάθε περίπτωση, τον έλεγχο του out-of-the-box δείχνει όλα τα διαθέσιμα στοιχεία από τη λίστα πηγή. Εάν ο κατάλογος προέλευσης έχει 1,000 στοιχεία, Αυτό πρόκειται να είναι ένα πρόβλημα. Τον έλεγχο της αναζήτησης δεν ξεφυλλίσετε εκείνα τα στοιχεία. Αντί, τραβά όλα αυτά στο στοιχείο ελέγχου. Αυτό κάνει για μια πολύ δύσκολη user επεμβαίνω, τόσο όσον αφορά την εισαγωγή δεδομένων και απόδοση.
  • Αναζητήσεις "τραβήξτε προς τα πίσω" μία στήλη των πληροφοριών. Ποτέ δεν μπορεί να τραβάτε πίσω περισσότερες από μία στήλες πληροφοριών από τη λίστα πηγή. Για παράδειγμα, δεν μπορείτε να επιλέξετε έναν πελάτη «12345" και να εμφανίσει τον αριθμό καθώς και όνομα και διεύθυνση του πελάτη, την ίδια στιγμή. Η αναζήτηση εμφανίζει μόνο ο πελάτης αριθμό και τίποτα άλλο. Αυτό κάνει για ένα αδέξιο και δύσκολο περιβάλλον εργασίας χρήστη.
  • Δεν ενδο-φόρμα επικοινωνίας. Έχω γράψει για αυτό εδώ. Δεν είναι δυνατό να υλοποιείτε επικαλυπτόμενα αναπτυσσόμενες λίστες, υπό όρους ενεργοποίηση/απενεργοποίηση πεδία, κλπ.
  • Καμία διαδοχικές διαγραφές ή ενσωματωμένο ακεραιότητας αναφορών. SharePoint αντιμετωπίζει προσαρμοσμένες λίστες ως ανεξάρτητες οντότητες και δεν σας επιτρέπουν να συνδέσω μεταξύ τους, με μια παραδοσιακή έννοια ERD. Για παράδειγμα, SharePoint σας επιτρέπει να δημιουργήσετε δύο προσαρμοσμένες λίστες, «πελάτη" και "επικεφαλίδα τιμολογίου". Μπορείτε να δημιουργήσετε μια επικεφαλίδα τιμολογίου που συνδέει πίσω σε έναν πελάτη στον κατάλογο πελατών. Στη συνέχεια, Μπορείτε να διαγράψετε τον πελάτη από τη λίστα. Από το κουτί, δεν υπάρχει κανένας τρόπος να αποτραπεί αυτό. Για την επίλυση του προβλήματος, σας κανονικά θα χρησιμοποιήσει δείκτες χειρισμού συμβάντων.

Μπορεί να φαίνεται δυσοίωνο, αλλά ακόμα θα χρήση του SharePoint ως αφετηρία για την οικοδόμηση αυτού του είδους της λειτουργικότητας. Αν και υπάρχουν κενά μεταξύ ό, τι χρειάζεστε σε ένα διάλυμα, SharePoint μας επιτρέπει να συμπληρώσουμε αυτά τα κενά χρησιμοποιώντας εργαλεία όπως:

  • Δείκτες χειρισμού συμβάντων. Χρησιμοποιήστε τους για να επιβάλλετε αναφορική ακεραιότητα.
  • Προσαρμοσμένων στηλών: Δημιουργία προσαρμοσμένων στήλη τύπων και τη χρήση τους, αντί για τη στήλη αναζήτησης προεπιλογής. Προσθέστε σελιδοποίησης, λειτουργίας buffering και τα χαρακτηριστικά του AJAX για να ανταποκρίνονται.
  • BDC. Αυτό το χαρακτηριστικό μόνο ΒΡΎΑ μας δίνει τη δυνατότητα σε λίστες του SharePoint άλλα με μια ανώτερη διεπαφή χρήστη για τη στήλη αναζήτησης συνηθισμένο ερώτημα. BDC επίσης μπορεί να φτάσει σε μια εφαρμογή διακομιστή πίσω τέλος. Χρήση BDC για την αποφυγή της αναπαραγωγής. Αντί να αναπαράγει τις πληροφορίες των πελατών από παρασκηνιακή ERP σύστημα, χρήση BDC αντί. Χαρακτηριστικά BDC παρέχουν μια ωραία διεπαφή χρήστη να τραβήξει αυτά τα στοιχεία άμεσα από το ERP σύστημα όπου ανήκει και αποφεύγει την ταλαιπωρία του στη διατήρηση μια λύση αναπαραγωγής.

    BDC είναι ένα χαρακτηριστικό γνώρισμα MOSS (δεν είναι διαθέσιμη στο WSS) και είναι δύσκολο να ρυθμίσετε.

  • Φόρμα web του ASP.NET: Δημιουργήσετε ένα πλήρης-χαρακτηρισμένο AJAX-enabled φόρμα που θα χρησιμοποιεί τις υπηρεσίες SharePoint αντικείμενο μοντέλο και/ή web για τη μόχλευση λίστες του SharePoint, ενώ παρέχει ένα περιβάλλον εργασίας χρήστη υψηλό βαθμό ετοιμότητας.

Η τελευταία επιλογή μπορεί να αισθάνονται σαν να ξεκινάτε από το μηδέν, αλλά εξετάστε το γεγονός ότι η πλατφόρμα του SharePoint ξεκινά σας με τα ακόλουθα βασικά χαρακτηριστικά:

  • Μοντέλο ασφαλείας με συντήρηση.
  • Σύστημα μενού με συντήρηση.
  • "Κύριο πίνακα" (ήτοι. προσαρμοσμένες λίστες) με ασφάλεια, ενσωματωμένο συντήρηση και έλεγχος.
  • Αναζήτηση.
  • Παρασκηνιακή εργαλεία ολοκλήρωσης (BDC).

Αν ξεκινήσετε με ένα νέο κενό σχέδιο στο visual studio, έχετε πολλή υποδομής και ειδών υγιεινής για την κατασκευή προτού να πάρετε κοντά σε αυτό που προσφέρει το SharePoint.

Πιστεύω ότι η Microsoft σκοπεύει να επεκτείνει SharePoint προς αυτή την κατεύθυνση της ανάπτυξης των εφαρμογών. Φαίνεται σαν μια φυσική επέκταση με το υπάρχον SharePoint βάσης. Εφαρμογή της Microsoft CRM παρέχει μεγάλη επεκτασιμότητα από τα είδη που απαιτούνται για την υποστήριξη της ανάπτυξης εφαρμογών κεφαλίδα/λεπτομέρεια. Αν και αυτά τα χαρακτηριστικά είναι στο CRM, η τεχνολογία είναι προφανώς διαθέσιμα στην ομάδα ανάπτυξης του SharePoint και αναμένω ότι θα κάνει το δρόμο του στο SharePoint προϊόν από το τέλος του 2008. Αν κάποιος έχει μια γνώση ή την διορατικότητα σε αυτό, Παρακαλώ αφήστε ένα σχόλιο.

</Τέλος>

5 thoughts on «Εφαρμογή Master / Λεπτομέρεια σχέσεις χρησιμοποιώντας προσαρμοσμένες λίστες

  1. Paul Galvin

    Raghu, Δεν νομίζω ότι υπάρχει οποιαδήποτε εύκολος τρόπος να το κάνουμε αυτό. Εγώ θα επικεντρωθεί στην επιμόρφωση τους χρήστες σας, όταν για να χρησιμοποιήσω που ένα από αυτά και ίσως να τους δώσουμε μια υπόδειξη με το όνομα του περιεχομένου πληκτρολογήστε ίδια. Δεν νομίζω να καρφώσετε πραγματικά αυτό, τεχνικά.

  2. Raghu έγραψε:
    Είμαι δημιουργία γονικού/θυγατρικού realationship χρησιμοποιώντας δύο τύπους περιεχομένου και προσαρμοσμένη λίστα, όπως εξηγείται στην το παραπάνω commnet. Αλλά έχω ένα πρόβλημα; Πρέπει να μην είναι διαθέσιμος στοιχείο Τύπος περιεχομένου δεν είναι διαθέσιμη σε επίπεδο φακέλου και τύπος περιεχομένου φακέλου κάθε είδος. Παρακαλώ οδηγός μου σε αυτό το σημείο. Ευχαριστώ…
  3. Michael Vickers

    Είναι ένα κομμάτι της kludge αλλά μπορώ να χρησιμοποιήσω ένα αναπτυσσόμενο ASP.Net που σκιές της αναζήτησης "dropdown" που δημιουργούνται από το SharePoint. Επισημαίνω το ASP.Net αναπτυσσόμενο μενού με μια προέλευση δεδομένων που βασίζεται στον κατάλογο που περιέχει το στοιχείο της αναζήτησης, που μου επιτρέπει να χρησιμοποιήσετε το πεδίο "αναγνωριστικό" ως η τιμή και η στήλη της επιλογής μου ως κείμενο προς εμφάνιση. Δεν δεσμεύουν το ASP.Net αναπτυσσόμενο μενού στο πεδίο αναζήτησης λίστα, επειδή δημιουργεί σφάλματα διακομιστή.

    Στη σελίδα φόρτωσης χρησιμοποιώ javascript για να αντιστοιχίσετε τη σωστή τιμή για την αναπτυσσόμενη λίστα ASP.Net, και κατόπιν να επισυνάψετε onchange εκδηλώσεις στο εν λόγω λίστα για να αντιστοιχίσετε νέες τιμές για την αντίστοιχη λίστα αναζήτησης του SharePoint. Κρύβω πραγματικά τη γραμμή που περιέχει η αναπτυσσόμενη λίστα SharePoint.

    Ένα τελευταίο πράγμα — λόγω του τρόπου SharePoint καθιστά ανόητος αναζήτησης αναπτυσσόμενα μενού, όταν ο αριθμός των ειδών που παίρνει παρελθόν 20 Χρησιμοποιώ έθιμο περιτύλιγμα αντικείμενο να get/set η τιμή αναπτυσσόμενης λίστας. Έχω μια θέση blog λεπτομερώς αυτή τη διαδικασία εδώ:

    http://www.idiotsyncrasies.com/2007/12/lookup-list-dropdowns-in-sharepoint.aspx

    Γεια,

    Μιχαήλ

  4. David

    Μπορείτε να δημιουργήσετε έναν τύπο περιεχομένου για την επικεφαλίδα τιμολογίου ανάλογα με τον τύπο περιεχομένου φάκελο και στη συνέχεια δημιουργήστε ένα άλλο τύπο περιεχομένου τιμολόγιο και να το πρόσθεταν και ο δύο σε μια λίστα του SharePoint. Αυτό στην πραγματικότητα δημιουργεί μια σχέση γονέα/παιδιού, η οποία θα σας επιτρέψει να δημιουργήσετε πολλαπλά τιμολόγια ανάλογα με τον τύπο περιεχομένου τιμολόγιο που ζουν στην περιοχή ο τύπος περιεχομένου κεφαλίδα τιμολόγιο που σας δίνει και την άμεση σχέση μεταξύ των δύο στοιχείων και εάν η επικεφαλίδα τιμολογίου είναι στοιχείο λίστας διαγραφεί όλα τα στοιχεία τιμολογίου παιδί μέσα σε αυτόν το φάκελο θα διαγραφούν. Μπορείτε επίσης να καθορίσετε ότι μόνο έναν τύπο περιεχομένου είναι διαθέσιμες μέσα από ένα συγκεκριμένο φάκελο. Αυτή η προσέγγιση είναι παρόμοια με το πώς η συζήτηση βιβλιοθήκη λειτουργεί και είναι πολύ χρήσιμη για αυτό το είδος της σχέσης μεταξύ των στοιχείων. Δείκτες χειρισμού συμβάντων και κώδικα θα βοηθήσει με κάποιους άλλους περιορισμούς αλλά συνολικά μια γρήγορη εύκολη λύση.

Αφήστε μια απάντηση, να Raghu έγραψε: Ακύρωση απάντησης

Η διεύθυνση email σας δεν θα δημοσιευθεί. τα απαιτούμενα πεδία είναι επισημασμένα *