IdentityServer از زمان ارائه‌ی نگارش 5 آن دیگر رایگان نیست و پیشتر
مایکروسافت از نگارش 4 آن در قالب‌های استاندارد پروژه‌های Blazor استفاده
کرده بود. نگارش قبلی آن تنها در پروژه‌های NET 5x. پشتیبانی خواهد شد.
نگارش 5 آن در پروژه‌های NET 6x. به همراه ذکر دقیق مجوز آن هنوز هم حضور
خواهد داشت. از نگارش 7 دات نت، فکر دیگری خواهند کرد.
Notepad++ برنامه‌ی رایگانی است برای ویرایش کدها با قابلیت syntax highlighting بسیار عالی و درخور توجه به همراه یک دو جین افزونه که قابلیت‌های آنرا افزایش می‌دهند.
قبل از این برنامه، از ultra-edit برای ویرایش‌های "دم دستی" استفاده می‌کردم و اگر قابلیت‌های این دو را مقایسه کنیم، پس از نصب افزونه‌های NP++ ، این برنامه چیزی کمتر از برنامه‌ی غیر رایگان ultra-edit نخواهد داشت.
افزونه‌ی SVN برای NP++
- Identity server یک محصول کاملا مجزای از ASP.NET Core Identity است و توسط تیم دیگری خارج از مایکروسافت توسعه داده می‌شود و این دو ارتباطی به هم ندارند.
- هرچند امکان استفاده‌ی از ASP.NET Core Identity برای مدیریت کاربران Identity server هم وجود دارد.
- کاری که در این سری انجام شده، ابتدا در «قسمت چهارم - نصب و راه اندازی IdentityServer» فایل‌های Quick Start UI را به پروژه‌ی IDP اضافه کردیم (یعنی دقیقا از کدهای اصلی تیم Identity server استفاده شده). بعد در این قسمت، سایر کدهای اصلی بسته‌ی EF Core آنرا (^ و ^) به پروژه اضافه و سفارشی سازی کرده و در قسمت‌های دیگر، این کدها را تکمیل کرده‌ایم. بنابراین در این سری از کدهای استاندارد خود Identity server استفاده شده و سپس توسعه‌ی بیشتری پیدا کرده‌اند. برای نمونه کلاس‌های موجودیت‌های مثال این سری، از اینجا تامین شده‌اند.
اگر مدت‌ها کارتان برنامه نویسی WinForms بوده و اکنون احساس کرده‌اید که دیگر WinForms آنچنان توسعه و بسط نخواهد یافت و اکنون WPF تبدیل به انتخاب اصلی شرکت‌های بزرگ شده است و همچنین از پرسه زدن در فوروم‌های وارز جهت یافتن فلان کامپوننت خاص برای زیباسازی ظاهر برنامه‌های خود خسته شده‌اید و نیاز به معادل بهتری که اساسا در جهت حذف این بازار سیاه تهیه شده است، احساس می‌کنید، بهترین گزینه‌ی موجود WPF خواهد بود که با کمی دقت، می‌توان پروژه‌های آنرا تبدیل به پروژه‌های وب نیز نمود. مطلب 54 صفحه‌ای ذیل، خلاصه‌ی کاربردی سریعی را جهت ارتقاء برنامه نویس‌های WinForms به WPF ارائه می‌دهد:
ماخذ
سلام . خسته نباشید.
سوالی داشتم ، اگر به عنوان مثال من دو کلاس شرکت و کارمند رو داشته باشم که رابطه یک به چند دارند. و هر کاربری که login کرد لازم باشه که فقط اطلاعات شرکت خودش رو ببینه ولی تنها role admin لازمه که اطلاعات همه شرکت رو پس از login ببیند. در اینصورت به نظر شما نیازی هست که از Claim base استفاده کنم با توجه به معایبی که گفته شده یا خیر؟
ممنونم
نمی توان گفت دلیل عدم موفقیت برخی از شرکت‌ها پاسخ ندادن به سوالات فوق است اما می‌توان ادعا کرد که دلیل عدم موفقیت،ممکن است عدم طرح شدن سوالات فوق باشد. پروژه به یک تلاش موقت برای خلق یک خروجی یکتا گفته می‌شود اما محصول هر موجودیتی است که شما برای برآورده کردن نیاز یا خواسته وارد بازار می‌کنید. مدیر پروژه مسئول برآورده کردن اهداف از پیش تعیین شده با استفاده از تیم توسعه است و مدیر محصول، مسئول برآورده شدن تمامی نیازیها مشتریان، سود اقتصادی سازمان و مزیت‌های رقابتی پایدار محصول است.
شما در حال توسعه کدام یک هستید؟ محصول یا پروژه؟
در قسمت آخر این سری، نگاهی خواهیم داشت به نحوه‌ی توزیع برنامه‌های React و نکات مرتبط با آن.
افزودن متغیرهای محیطی
در برنامه‌ی نمایش لیست فیلم‌هایی که تا قسمت 29 آنرا بررسی کردیم، از فایل src\config.json برای ذخیره سازی اطلاعات تنظیمات برنامه استفاده شد. هرچند این روش کار میکند اما بر اساس محیط‌های مختلف توسعه، متغیر نیست. اغلب برنامه‌ها باید بتوانند حداقل در سه محیط توسعه، آزمایش و تولید، بر اساس متغیرها و تنظیمات خاص هر کدام، کار کنند. برای مثال بر روی سیستمی که کار توسعه در آن انجام می‌شود، می‌خواهیم apiUrl متفاوتی را نسبت به حالتیکه برنامه توزیع می‌شود، داشته باشیم.
برای رفع این مشکل، برنامه‌هایی که توسط create-react-app تولید می‌شوند، دارای پشتیبانی توکاری از متغیرهای محیطی هستند. برای این منظور نیاز است در ریشه‌ی پروژه (جائیکه فایل package.json قرار دارد) فایل جدید env. را ایجاد کرد. در ویندوز برای ایجاد یک چنین فایل‌هایی که فقط از یک پسوند تشکیل می‌شوند، باید نام فایل را به صورت .env. وارد کرد؛ سپس خود ویندوز نقطه‌ی نهایی را حذف میکند. البته اگر از ادیتور VSCode برای ایجاد این فایل استفاده می‌کنید، نیازی به درج نقطه‌ی انتهایی نیست. در این فایل environment ایجاد شده می‌توان تمام متغیرهای محیطی مورد نیاز را با مقادیر پیش‌فرض آنها درج کرد. همچنین می‌توان این مقادیر پیش‌فرض را بر اساس محیط‌های مختلف کاری، بازنویسی کرد. برای مثال می‌توان فایل env.development. را اضافه کرد؛ به همراه فایل‌های env.test. و env.production.
متغیرهای محیطی به صورت key=value درج می‌شوند. این کلیدها نیر باید با REACT_APP_ شروع شوند؛ در غیر اینصورت، کار نخواهند کرد. برای مثال در فایل env.، دو متغیر پیش‌فرض زیر را تعریف میکنیم:
اکنون برای خواندن این متغیرها برای مثال در فایل index.js (و یا هر فایل جاوا اسکریپتی دیگری در برنامه)، سطر زیر را درج میکنیم:
process به معنای پروسه‌ی جاری برنامه‌است (و مرتبط است به پروسه‌ی node.js ای که برنامه‌ی React را اجرا میکند) و خاصیت env، به همراه تمام متغیرهای محیطی برنامه می‌باشد. در این حالت اگر برنامه را اجرا کنیم، در کنسول توسعه دهندگان مرورگر، به یک چنین خروجی خواهیم رسید:
در این خروجی، متغیر "NODE_ENV: "development به صورت خودکار با تولید بسته‌های مخصوص ارائه‌ی نهایی، به production تنظیم می‌شود. سایر متغیرهای محیطی تعریف شده را نیز در اینجا ملاحظه می‌کنید. با توجه به خواص شیء env، برای مثال جهت دسترسی به نام برنامه می‌توان از مقدار process.env.REACT_APP_NAME استفاده کرد.
یک نکته: با هر تغییری در مقادیر متغیرهای محیطی، نیاز است یکبار دیگر برنامه را از ابتدا توسط دستور npm start، راه اندازی مجدد کرد؛ چون این فایل‌ها به صورت خودکار ردیابی نمی‌شوند.
نحوه‌ی پردازش متغیرهای محیطی درج شده‌ی در برنامه
اگر همان سطر لاگ کردن خروجی process.env را به صورت زیر تغییر دهیم:
و برنامه را مجددا اجرا کنیم، با مراجعه‌ی به برگه‌ی Sources و انتخاب مسیر localhost:3000/static/js/main.chunk.js و سپس جستجوی "My App Name" ای که در اینجا اضافه کردیم (با فشردن دکمه‌های Ctrl+F)، به خروجی زیر خواهیم رسید:
همانطور که مشاهده می‌کنید، فراخوانی console.log ما، دیگر به همراه متغیر process.env.REACT_APP_NAME نیست؛ بلکه مقدار اصلی این متغیر در اینجا درج شده‌است. بنابراین اگر در در حین توسعه‌ی برنامه، از متغیرهای محیطی استفاده شود، این متغیرها با مقادیر اصلی آنها در حین پروسه‌ی Build نهایی، جایگزین می‌شوند.
Build برنامه‌های React برای محیط تولید
اجرای دستور npm start، سبب ایجاد یک Build مخصوص محیط توسعه می‌شود که بهینه سازی نشده‌است و به همراه اطلاعات اضافی قابل توجهی جهت دیباگ ساده‌تر برنامه‌است. برای رسیدن به یک خروجی بهینه سازی شده‌ی مخصوص محیط تولید و ارائه‌ی نهایی باید دستور npm run build را در خط فرمان اجرا کرد. خروجی نهایی این دستور، در پوشه‌ی جدید build واقع در ریشه‌ی پروژه، قرار میگیرد. اکنون می‌توان کل محتویات این پوشه را جهت ارائه‌ی نهایی در وب سرور خود، مورد استفاده قرار داد.
پس از پایان اجرای دستور npm run build، پیام «امکان ارائه‌ی آن توسط static server زیر نیز وجود دارد» ظاهر می‌شود:
اگر علاقمند باشید تا خروجی حالت production تولید شده را نیز به صورت محلی آزمایش کنید، ابتدا باید static server یاد شده را توسط دستور npm install فوق نصب کنید. سپس ریشه‌ی پروژه را در خط فرمان باز کرده و دستور serve -s build را صادر کنید (البته اگر با خط فرمان به پوشه‌ی build وارد شدید، دیگر نیازی به ذکر پوشه‌ی build نخواهد بود). اکنون می‌توانید برنامه را در آدرس http://localhost:5000 در مرورگر خود بررسی نمائید.
البته با توجه به اینکه backend سرور برنامه‌های ما نیز در همین آدرس قرار دارد و در صورت ورود این آدرس، به صورت خودکار به https://localhost:5001/index.html هدایت خواهید شد، می‌توان این پورت پیش‌فرض را با اجرای دستور serve -s build -l 1234 تغییر داد. اکنون می‌توان آدرس جدید http://localhost:1234 را در مرورگر آزمایش کرد که ... با خطای زیر کار نمی‌کند:
روش رفع این مشکل را در قسمت 23 بررسی کردیم و در اینجا جهت بهبود آن می‌توان متد WithOrigins فایل Startup.cs را به صورت زیر تکمیل کرد:
یک نکته: زمانیکه از دستور npm start استفاده می‌شود، متغیرهای محیطی از فایل env.development. خوانده خواهند شد و زمانیکه از دستور npm run build استفاده می‌شود، این متغیرها از فایل env.production. تامین می‌شوند. در این حالت‌ها اگر متغیری در این دو فایل درج نشده بود، از مقدار پیش‌فرض موجود در فایل env. استفاده می‌گردد. از فایل env.test. با اجرای دستور npm test، به صورت خودکار استفاده می‌شود.
آماده سازی برنامه‌ی React، برای توزیع نهایی
تا اینجا برنامه‌ی React تهیه شده، اطلاعات apiUrl خودش را از فایل config.json دریافت میکند. اکنون می‌خواهیم بر اساس حالات مختلف توسعه و تولید، از apiUrlهای متفاوتی استفاده شود. به همین جهت به فایل env.production. مراجعه کرده و تنظیمات ذیل را به آن اضافه میکنیم:
البته فعلا همین متغیرها را به فایل env.development. نیز می‌توان اضافه کرد؛ چون backend سرور ما در هر دو حالت، در این مثال، در آدرس فوق قرار دارد.
اکنون به برنامه مراجعه کرده و در هرجائی که ارجاعی به فایل config.json وجود دارد، سطر import آنرا حذف میکنیم. با این تغییر، تمام آدرس‌هایی مانند:
را به صورت زیر ویرایش میکنیم:
در ادامه برای تامین مقدار apiUrl به صورت خودکار، به فایل src\services\httpService.js مراجعه کرده و در ابتدای آن، یک سطر زیر را اضافه میکنیم:
به این ترتیب تمام درخواست‌های ارسالی توسط Axios، دارای baseURL ای خواهند شد که از فایل متغیر محیطی جاری تامین می‌شود. همانطور که پیشتر نیز عنوان شد، این مقدار در زمان Build، با مقدار ثابتی که از فایل env جاری خوانده می‌شود، جایگزین خواهد شد.
همچنین adminRoleName مورد نیاز در فایل src\services\authService.js را نیز از همان فایل env جاری تامین میکنیم:
پس از این تغییرات، نیاز است برای حالت توسعه، یکبار دیگر دستور npm start و یا برای حالت تولید، دستور npm run build را اجرا کرد تا اطلاعات درج شده‌ی در فایل‌های env.، پردازش و جایگزین شوند.
کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید: sample-34-frontend.zip و sample-34-backend.zip
افزودن متغیرهای محیطی
در برنامه‌ی نمایش لیست فیلم‌هایی که تا قسمت 29 آنرا بررسی کردیم، از فایل src\config.json برای ذخیره سازی اطلاعات تنظیمات برنامه استفاده شد. هرچند این روش کار میکند اما بر اساس محیط‌های مختلف توسعه، متغیر نیست. اغلب برنامه‌ها باید بتوانند حداقل در سه محیط توسعه، آزمایش و تولید، بر اساس متغیرها و تنظیمات خاص هر کدام، کار کنند. برای مثال بر روی سیستمی که کار توسعه در آن انجام می‌شود، می‌خواهیم apiUrl متفاوتی را نسبت به حالتیکه برنامه توزیع می‌شود، داشته باشیم.
برای رفع این مشکل، برنامه‌هایی که توسط create-react-app تولید می‌شوند، دارای پشتیبانی توکاری از متغیرهای محیطی هستند. برای این منظور نیاز است در ریشه‌ی پروژه (جائیکه فایل package.json قرار دارد) فایل جدید env. را ایجاد کرد. در ویندوز برای ایجاد یک چنین فایل‌هایی که فقط از یک پسوند تشکیل می‌شوند، باید نام فایل را به صورت .env. وارد کرد؛ سپس خود ویندوز نقطه‌ی نهایی را حذف میکند. البته اگر از ادیتور VSCode برای ایجاد این فایل استفاده می‌کنید، نیازی به درج نقطه‌ی انتهایی نیست. در این فایل environment ایجاد شده می‌توان تمام متغیرهای محیطی مورد نیاز را با مقادیر پیش‌فرض آنها درج کرد. همچنین می‌توان این مقادیر پیش‌فرض را بر اساس محیط‌های مختلف کاری، بازنویسی کرد. برای مثال می‌توان فایل env.development. را اضافه کرد؛ به همراه فایل‌های env.test. و env.production.
متغیرهای محیطی به صورت key=value درج می‌شوند. این کلیدها نیر باید با REACT_APP_ شروع شوند؛ در غیر اینصورت، کار نخواهند کرد. برای مثال در فایل env.، دو متغیر پیش‌فرض زیر را تعریف میکنیم:
REACT_APP_NAME=My App REACT_APP_VERSION=1
console.log(process.env);
در این خروجی، متغیر "NODE_ENV: "development به صورت خودکار با تولید بسته‌های مخصوص ارائه‌ی نهایی، به production تنظیم می‌شود. سایر متغیرهای محیطی تعریف شده را نیز در اینجا ملاحظه می‌کنید. با توجه به خواص شیء env، برای مثال جهت دسترسی به نام برنامه می‌توان از مقدار process.env.REACT_APP_NAME استفاده کرد.
یک نکته: با هر تغییری در مقادیر متغیرهای محیطی، نیاز است یکبار دیگر برنامه را از ابتدا توسط دستور npm start، راه اندازی مجدد کرد؛ چون این فایل‌ها به صورت خودکار ردیابی نمی‌شوند.
نحوه‌ی پردازش متغیرهای محیطی درج شده‌ی در برنامه
اگر همان سطر لاگ کردن خروجی process.env را به صورت زیر تغییر دهیم:
console.log("My App Name", process.env.REACT_APP_NAME); 
همانطور که مشاهده می‌کنید، فراخوانی console.log ما، دیگر به همراه متغیر process.env.REACT_APP_NAME نیست؛ بلکه مقدار اصلی این متغیر در اینجا درج شده‌است. بنابراین اگر در در حین توسعه‌ی برنامه، از متغیرهای محیطی استفاده شود، این متغیرها با مقادیر اصلی آنها در حین پروسه‌ی Build نهایی، جایگزین می‌شوند.
Build برنامه‌های React برای محیط تولید
اجرای دستور npm start، سبب ایجاد یک Build مخصوص محیط توسعه می‌شود که بهینه سازی نشده‌است و به همراه اطلاعات اضافی قابل توجهی جهت دیباگ ساده‌تر برنامه‌است. برای رسیدن به یک خروجی بهینه سازی شده‌ی مخصوص محیط تولید و ارائه‌ی نهایی باید دستور npm run build را در خط فرمان اجرا کرد. خروجی نهایی این دستور، در پوشه‌ی جدید build واقع در ریشه‌ی پروژه، قرار میگیرد. اکنون می‌توان کل محتویات این پوشه را جهت ارائه‌ی نهایی در وب سرور خود، مورد استفاده قرار داد.
پس از پایان اجرای دستور npm run build، پیام «امکان ارائه‌ی آن توسط static server زیر نیز وجود دارد» ظاهر می‌شود:
> npm install -g serve > serve -s build
البته با توجه به اینکه backend سرور برنامه‌های ما نیز در همین آدرس قرار دارد و در صورت ورود این آدرس، به صورت خودکار به https://localhost:5001/index.html هدایت خواهید شد، می‌توان این پورت پیش‌فرض را با اجرای دستور serve -s build -l 1234 تغییر داد. اکنون می‌توان آدرس جدید http://localhost:1234 را در مرورگر آزمایش کرد که ... با خطای زیر کار نمی‌کند:
Access to XMLHttpRequest at 'https://localhost:5001/api/genres' from origin 'http://localhost:1234' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
WithOrigins("http://localhost:3000", "http://localhost:1234") یک نکته: زمانیکه از دستور npm start استفاده می‌شود، متغیرهای محیطی از فایل env.development. خوانده خواهند شد و زمانیکه از دستور npm run build استفاده می‌شود، این متغیرها از فایل env.production. تامین می‌شوند. در این حالت‌ها اگر متغیری در این دو فایل درج نشده بود، از مقدار پیش‌فرض موجود در فایل env. استفاده می‌گردد. از فایل env.test. با اجرای دستور npm test، به صورت خودکار استفاده می‌شود.
آماده سازی برنامه‌ی React، برای توزیع نهایی
تا اینجا برنامه‌ی React تهیه شده، اطلاعات apiUrl خودش را از فایل config.json دریافت میکند. اکنون می‌خواهیم بر اساس حالات مختلف توسعه و تولید، از apiUrlهای متفاوتی استفاده شود. به همین جهت به فایل env.production. مراجعه کرده و تنظیمات ذیل را به آن اضافه میکنیم:
REACT_APP_API_URL=https://localhost:5001/api REACT_APP_ADMIN_ROLE_NAME=Admin
اکنون به برنامه مراجعه کرده و در هرجائی که ارجاعی به فایل config.json وجود دارد، سطر import آنرا حذف میکنیم. با این تغییر، تمام آدرس‌هایی مانند:
const apiEndpoint = apiUrl + "/users";
const apiEndpoint = "/users";
axios.defaults.baseURL = process.env.REACT_APP_API_URL;
همچنین adminRoleName مورد نیاز در فایل src\services\authService.js را نیز از همان فایل env جاری تامین میکنیم:
const adminRoleName = process.env.REACT_APP_ADMIN_ROLE_NAME;
کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید: sample-34-frontend.zip و sample-34-backend.zip
معمولا معماری‌های ارائه شد،ه بر اساس جداسازی لایه‌های نرم‌افزار می‌باشد. برای مثال در معماری Hexagonal که آنرا به Port & Adaptor هم میشناسیم، نرم‌افزار، با استفاده از لایه‌های Domain، Application، Infra و ... تفکیک می‌شوند. منطق تجاری در Domain پیاده سازی می‌شود و رابطهای مربوط به کار با دیتا تعریف می‌شوند. در لایه‌ی Application، Portها و Adaptorهای مورد نیاز برای استفاده، پیاده‌سازی می‌شوند. در لایه‌ی Infra، رابطهای تعریف شده در Domain پیاده‌سازی شده و در لایه‌ی Application، Adaptorهای پیاده‌سازی شده مورد استفاده قرار میگیرند.
تمام این اتفاقات در سطح لایه‌های برنامه اتفاق می‌افتند و بر همین اساس ما نیاز داریم برای جلوگیری از تغییرات بزرگ، از Abstraction استفاده کنیم و بسیار زیاد استفاده میکنیم. Abstraction یکی از راه‌های غیرمستقیم (InDirection) کردن دسترسی فراخوان به منبع یا تارگت مورد نظر می‌باشد که مزایای زیادی را مانند استفاده‌ی مجدد، جداسازی بخش‌هایی که باعث پیچیدگی می‌شوند و همچنین مخفی کردن وابستگی‌ها برای ما دارد.
می‌دانیم که غیرمستقیم کردن دسترسی به منابع در طراحی نرم‌افزار یک اصل است. اما Abstraction تنها راه جداسازی نیست. راه دیگر طراحی زیرساخت می‌باشد. مانند استفاده از Message Queue (مانند استفاده از MediatR) و یا Load Balancer.
البته منظور این نیست که استفاده‌ی غیر مستقیم از لایه‌های نمایش داده شده را حذف کنیم. مشخصا MediatR در اینجا جداسازی خوبی را برای ما ایجاد کرده که مزایای آن بر کسی پوشیده نیست. مسئله‌ی مهمی که معمولا به آن توجهی نمیشود، هزینه‌ی Abstraction می‌باشد. اگر بخواهیم درباره‌ی هزینه‌های Abstraction صحبت کنیم، اشاره به موارد زیر قابل تامل است:
ابتدا، فهم سخت بعد از استفاده از Abstraction می‌باشد. در واقع ما با ایجاد این Abstractionها، مسیر رسیدن به هدف را در بین یکسری لایه‌ها قرار داده‌ایم که فهم دقیق آنها، ارتباط مستقیمی با منطق پیاده‌سازی ما دارد. البته مزیت اینکار عدم درگیری با لایه‌های مشخص شده می‌باشد.
دوم کارآیی پایین. البته فقط صحبت در مورد مصرف زیاد حافظه و یا CPU نیست. یکی از این موارد، به دلیل Generic تعریف شدن Repositoryها می‌باشد که باعث می‌شود داده‌های بیشتر از نیازی را به لایه‌های دیگر ارسال کنیم. برای بررسی دقیق‌تر می‌توانید این مقاله را مطالعه بفرمایید.
اما Vertical Slices چگونه به ما در این زمینه کمک میکند. در این معماری، ما به جای تمرکز بر روی لایه‌ها، تمرکز خود را روی فیچرها میگذاریم. در واقع نرم‌افزار را به قسمت‌های بسیار کوچکتری تقسیم میکنیم و از Abstraction اضافی جلوگیری میکنیم. در این صورت اگر تغییری لازم به اعمال شدن دارد، در سطح فیچر اعمال می‌شود و نه در سطح لایه‌ها. در ضمن دیگر Repository و یا Specification ی برای تست وجود ندارد؛ پس میزان تست‌های نوشته شده کاهش پیدا می‌کنند و طبیعتا برای تست Integration میتوانیم کل فیچر را تست کنیم.
در اینجا ما بجای تمرکز بر روی ساختار کل کدبیس، تمرکز خود را بر روی ساختار کدبیس یک فیچر خاص نگه میداریم.
در Vertical Slices Arch ما مشکلی با اشتراک‌گذاری Domain بین فیچرها نداریم. زیرا Domain ما به هیچ فریموورکی وابسته نیست و بصورت مستقیم مورد استفاده قرار میگیرد. لطفا به تصویر زیر توجه بفرمایید:
زمانیکه این فیچرهای کوچک توسعه داده می‌شوند، دلیلی برای تعریف Repository و یا Specificationهای بی مورد نداریم. پس میتوانیم به راحتی آنها را حذف کنیم و به صورت مستقیم از EF و یا هر ORM دیگری استفاده کنیم و یا میتوانیم به راحتی از Raw Queryها و مزیت آنها بهره‌مند شویم. نگه‌داری یک فیچر کوچک که Command، Handler و Viewها و سایر نیازمندی‌هایش(به استثنای Domain) داخل خودش قرار گرفته و شامل یک ساختار ویژه‌ی خودش با توجه به نیازمندی‌های تعریف شده می‌باشد، بسیار کار ساده‌تری است تا نگه‌داری یک سری لایه که به صورت گسترده از Abstraction در آنها استفاده شده‌است.
چنانکه در مقاله قبلی هم گفتم بومی‌سازی صرفا در ترجمه خلاصه نمیشود و یک فرآیند است. امروز یک مثال کوچک از روند بومی‌سازی در ارائه ایده‌ها به سرمایه‌گذاران را با هم بررسی خواهیم کرد.
در کشورهایی که فرهنگ راه‌اندازی استارتاپ‌ها جا افتاده است، سرمایه‌گذاران در جستجوی ایده‌های ناب و تیم‌های موفق هستند تا با سرمایه‌گذاری بر روی آنها در اندک زمانی سرمایه‌شان را چند برابر کنند. اما معمولا روند این کار برعکس است، به این معنی که معمولا شخصی که ایده دارد در جستجوی سرمایه‌گذار به دفتر او (که معمولا در طبقات بالایی برج‌های بلند هستند) رفته و سعی در ارائه ایده‌اش به سرمایه‌گذار میکند. مشخصا پیدا کردن و گرفتن زمان از یک سرمایه‌گذار بسیار دشوار است، لذا تنها فرصتی که صاحبان ایده دارند زمانی است که سرمایه‌گذار وارد ساختمان شده، از آسانسور بالا رفته و وارد دفترش می‌شود. این زمان فرصتی کوتاه است که صاحب ایده، خودش، ایده‌اش، نقاط قوت ایده‌اش، طرح تجاری و دلایل سودآوری آن را به سرمایه‌گذار توضیح دهد. و همه این‌ها بصورت میانگین مفهومی به عنوان ارائه‌های آسانسوری (Elevator Presentation / Pitch) را برای همه نهادینه کرده. نهایتا در انتهای این یک دقیقه در صورتی که سرمایه‌گذار طرح را پذیرفت برای توضیحات بیشتر یک وقت دیگر برای توضیحات تکمیلی به صاحب ایده می‌دهد که این وقت مجدد معمولا فقط پنج دقیقه است. نهایتا تعداد این جلسات و زمان آنها بیشتر شده تا سرمایه‌گذار بپذیرد که روی ایده سرمایه‌گذاری کند.
اما هیچ‌کدام از اتفاقات بالا، در ایران قابل لمس نیست چراکه ما هنوز در ابتدای راه هستیم و مفهوم استارتاپ‌ها تازه در حال شکل‌گیری است، سرمایه‌گذاران هنوز بطور جدی به این طرح‌ها نگاه نمی‌کنند. اما اگر بخواهیم همین روند بالا را بومی کنیم. باید به این موارد دقت کنیم.
دفتر سرمایه‌گذاران ما معمولا در طبقات بالایی یک برج نیست. سرمایه‌گذاران ما معمولا یک ساختمان جداگانه برای خودشان دارند که در آن مستقر هستند حالا ممکن است این ساختمان چند طبقه باشد اما کل این مکان متعلق به شرکتی است که او اداره میکند و او در یک طبقه خاص مستقر است. فرهنگ ما به ما اجازه نمی‌دهد تا بدون وقت قبلی و با سرمایه‌گذار (که در اکثر مواقع شخص اصلی شرکت است) وارد شرکت شویم. وقتهای ارائه معمولا بصورت رابطهای و در صورتی که شخصی یک صاحب ایده را به سرمایه‌گذار معرفی کرده باشد تعیین خواهند شد. که متاسفانه زمان این جلسات به نسبت جدی بودن سرمایه‌گذار در سرمایه‌گذاری و توسط خود او تعیین می‌شود و شخص ارائه دهنده از قبل هیچ اطلاعی از اینکه چه زمانی را برای ارائه ایده‌اش در اختیار دارد، ندارد.
لذا با توجه به این موارد، ما در ایران جلسه اول و دوم را، معمولا یکی میکنیم. و متاسفانه بجای تاکید بر روی ایده و استارتاپ، در جلسه اول معمولا بیشتر بر روی خود روابط تاکید می‌شود تا یک اطمینان در هر دو طرف ایجاد شود. صاحبان ایده همیشه از این می‌ترسند که سرمایه‌گذار پس از شنیدن ایده بدون خود آنها اقدام به پیاده‌سازی آن کند، لذا در جلسات اول صرفا هر دو طرف اقدام به براندازی همدیگر کرده و با جملات نامفهوم از ایده اصلی سعی در به تعویق انداختن مباحث فنی کرده و صرفا سعی کنند از طرف مقابل مطمئن شوند.
اما آیا واقعا ما به ارائه‌های آسانسوری نیازی نداریم؟ جواب این سوال منفی است. چراکه گرچه با توجه به ساختار سرمایه‌گذاری در کشور ما نمی‌توانیم اقدام به برپایی ارائه آسانسوری با یک سرمایه‌گذار کنیم، اما اگر نتوانیم تمام مواردی که در مفهوم ارائه اسانسوری نهفته است را، در یک دقیقه به هر شخصی ارائه کنیم نشان‌دهنده این است که طرح ما واقعا برای سرمایه‌گذاری مناسب نیست. بهتر است برای خودتان و دوستانتان و اعضای تیمتان اقدام به برپایی این ارائه‌ها کنید تا نقاط مبهم برای خود شما مشخص شود. شاید واقعا باید بپذیرید که استارتاپ شما محکوم به شکست است.
نکته دیگری که در بومی‌سازی باید توجه داشت دقیقا همین مورد است. که همه چیز را نباید و نمی‌توان بومی کرد. ساختارهای کشور ما و آنچه ما با آنها درگیر هستیم تعیین کننده آن است که ایا باید چیزی را بومی کرد یا خیر. نظر شخص من این است که با توجه به فرهنگ کاریمان در ایران، در واقعیت، ما هیچگاه نخواهیم توانست به سمت ارائه‌های آسانسوری واقعی حرکت کنیم. لذا باید آنها را برای خودمان تمرین کنیم تا خودمان از شکست یا احتما پیروزی طرحمان اطمینان کسب کنیم.
نظر شما چیست؟
در کشورهایی که فرهنگ راه‌اندازی استارتاپ‌ها جا افتاده است، سرمایه‌گذاران در جستجوی ایده‌های ناب و تیم‌های موفق هستند تا با سرمایه‌گذاری بر روی آنها در اندک زمانی سرمایه‌شان را چند برابر کنند. اما معمولا روند این کار برعکس است، به این معنی که معمولا شخصی که ایده دارد در جستجوی سرمایه‌گذار به دفتر او (که معمولا در طبقات بالایی برج‌های بلند هستند) رفته و سعی در ارائه ایده‌اش به سرمایه‌گذار میکند. مشخصا پیدا کردن و گرفتن زمان از یک سرمایه‌گذار بسیار دشوار است، لذا تنها فرصتی که صاحبان ایده دارند زمانی است که سرمایه‌گذار وارد ساختمان شده، از آسانسور بالا رفته و وارد دفترش می‌شود. این زمان فرصتی کوتاه است که صاحب ایده، خودش، ایده‌اش، نقاط قوت ایده‌اش، طرح تجاری و دلایل سودآوری آن را به سرمایه‌گذار توضیح دهد. و همه این‌ها بصورت میانگین مفهومی به عنوان ارائه‌های آسانسوری (Elevator Presentation / Pitch) را برای همه نهادینه کرده. نهایتا در انتهای این یک دقیقه در صورتی که سرمایه‌گذار طرح را پذیرفت برای توضیحات بیشتر یک وقت دیگر برای توضیحات تکمیلی به صاحب ایده می‌دهد که این وقت مجدد معمولا فقط پنج دقیقه است. نهایتا تعداد این جلسات و زمان آنها بیشتر شده تا سرمایه‌گذار بپذیرد که روی ایده سرمایه‌گذاری کند.
اما هیچ‌کدام از اتفاقات بالا، در ایران قابل لمس نیست چراکه ما هنوز در ابتدای راه هستیم و مفهوم استارتاپ‌ها تازه در حال شکل‌گیری است، سرمایه‌گذاران هنوز بطور جدی به این طرح‌ها نگاه نمی‌کنند. اما اگر بخواهیم همین روند بالا را بومی کنیم. باید به این موارد دقت کنیم.
- زمان لازم برای ارائه اولیه (ارائه آسانسوری) در ایران چقدر باید باشد؟
- زمان ارائه دوم چقدر باید باشد؟
- چه نکاتی در ارائه اول و دوم باید گنجانده شود؟
دفتر سرمایه‌گذاران ما معمولا در طبقات بالایی یک برج نیست. سرمایه‌گذاران ما معمولا یک ساختمان جداگانه برای خودشان دارند که در آن مستقر هستند حالا ممکن است این ساختمان چند طبقه باشد اما کل این مکان متعلق به شرکتی است که او اداره میکند و او در یک طبقه خاص مستقر است. فرهنگ ما به ما اجازه نمی‌دهد تا بدون وقت قبلی و با سرمایه‌گذار (که در اکثر مواقع شخص اصلی شرکت است) وارد شرکت شویم. وقتهای ارائه معمولا بصورت رابطهای و در صورتی که شخصی یک صاحب ایده را به سرمایه‌گذار معرفی کرده باشد تعیین خواهند شد. که متاسفانه زمان این جلسات به نسبت جدی بودن سرمایه‌گذار در سرمایه‌گذاری و توسط خود او تعیین می‌شود و شخص ارائه دهنده از قبل هیچ اطلاعی از اینکه چه زمانی را برای ارائه ایده‌اش در اختیار دارد، ندارد.
لذا با توجه به این موارد، ما در ایران جلسه اول و دوم را، معمولا یکی میکنیم. و متاسفانه بجای تاکید بر روی ایده و استارتاپ، در جلسه اول معمولا بیشتر بر روی خود روابط تاکید می‌شود تا یک اطمینان در هر دو طرف ایجاد شود. صاحبان ایده همیشه از این می‌ترسند که سرمایه‌گذار پس از شنیدن ایده بدون خود آنها اقدام به پیاده‌سازی آن کند، لذا در جلسات اول صرفا هر دو طرف اقدام به براندازی همدیگر کرده و با جملات نامفهوم از ایده اصلی سعی در به تعویق انداختن مباحث فنی کرده و صرفا سعی کنند از طرف مقابل مطمئن شوند.
اما آیا واقعا ما به ارائه‌های آسانسوری نیازی نداریم؟ جواب این سوال منفی است. چراکه گرچه با توجه به ساختار سرمایه‌گذاری در کشور ما نمی‌توانیم اقدام به برپایی ارائه آسانسوری با یک سرمایه‌گذار کنیم، اما اگر نتوانیم تمام مواردی که در مفهوم ارائه اسانسوری نهفته است را، در یک دقیقه به هر شخصی ارائه کنیم نشان‌دهنده این است که طرح ما واقعا برای سرمایه‌گذاری مناسب نیست. بهتر است برای خودتان و دوستانتان و اعضای تیمتان اقدام به برپایی این ارائه‌ها کنید تا نقاط مبهم برای خود شما مشخص شود. شاید واقعا باید بپذیرید که استارتاپ شما محکوم به شکست است.
نکته دیگری که در بومی‌سازی باید توجه داشت دقیقا همین مورد است. که همه چیز را نباید و نمی‌توان بومی کرد. ساختارهای کشور ما و آنچه ما با آنها درگیر هستیم تعیین کننده آن است که ایا باید چیزی را بومی کرد یا خیر. نظر شخص من این است که با توجه به فرهنگ کاریمان در ایران، در واقعیت، ما هیچگاه نخواهیم توانست به سمت ارائه‌های آسانسوری واقعی حرکت کنیم. لذا باید آنها را برای خودمان تمرین کنیم تا خودمان از شکست یا احتما پیروزی طرحمان اطمینان کسب کنیم.
نظر شما چیست؟
مقدمه
با اجرای این مثال نتیجه زیر حاصل می‌شود:
همانطور که می‌بنید عملیات replace برای سایر توکن‌ها انجام نمیشود.
در این روش عملیات replace تا زمانیکه تغییری در رشته جاری ایجاد نشود ادامه می‌یابد. با استفاده از این متد، خروجی مثال قبل درست و به صورت زیر خواهد بود:
استفاده از این متد هم نتیجه درستی برای مثال آخر ارائه می‌دهد.
این متد نیز نتیجه مشابهی ارائه میکند. حال به مثال زیر توجه کنید:
خروجی صحیح مثال فوق باید به صورت زیر باشد:
درصورتی‌که رشته‌ای که دو متد از سه متد آخر (3 و 4) به عنوان خروجی ارائه می‌دهند به‌صورت زیر است:
برای آخرین متد که ازحلقه while (درواقع با اندیس معکوس) استفاده میکند (5) مثالی که خطای مورد بحث را نشان می‌دهد به صورت زیر است:
که خروجی اشتباه زیر را برمی‌گرداند:
درصورتی‌که باید مقدار زیر را برگشت دهد:
دلیل رخدادن این خطا اجرای عملیات replace به صورت جداگانه و کامل برای هر توکن، از اول تا آخر برای رشته‌های replace شده جاری است که کار را خراب میکند.
خروجی این مثال به‌صورت زیر است:
پیاده‌سازی زیر برای حل این مشکل استفاده می‌شود.
با استفاده از این متد جدید خروجی مثال‌های قبل درست خواهد بود.
که خروجی زیر را ارائه می‌دهد:
.
در اینجا با استفاده از یک عبارت RegExp پیچیده‌تر و کنترل تکرار کاراکترهای { و } در متد سفارشی جایگزینی در دستور replace، پیاده‌سازی اولیه این ویژگی ارائه شده است..
.
برای حالت prototype نیز داریم:
دقت کنید قسمت ابتدایی این متد که برای بررسی اعتبار آرگومان‌های ورودی است، برای سادگی عملیات کامنت شده است. همانطور که می‌بینید این متد پیاده‌سازی نسبتا مفصلی دارد و امکانات بیشتری نیز در اختیار برنامه نویسان قرار می‌دهد. البته سایر متدهای مربوطه بدلیل طولانی بودن در اینجا آورده نشده است. برای مثال امکانات پیشرفته‌تری مثل زیر با استفاده از این کتابخانه در دسترس هستند:
همانطور که می‌بینید این کتابخانه امکانات کامل‌تری نیز دارد. مثال‌های مربوط به این کتابخانه به صورت زیر هستند که توانایی‌های نسبتا کامل آنرا نشان می‌دهد:.
با اینکه زبان برنامه نویسی جاوا اسکریپت زبانی بسیار قدرتمند و با امکانات زیاد است، اما فقدان برخی متدهای کمکی پرمصرف در آن در برخی موارد باعث دردسرهایی می‌شود. امکانی برای فرمت‌بندی رشته‌ها یکی از این نیازهای نسبتا پرکاربرد است.
متدی که در این مطلب قصد توضیح پیاده‌سازی آنرا داریم، String.format نام دارد که فرایندی مشابه متد متناظر در دات نت را انجام می‌دهد. همچنین سعی شده است تا نحوه پیاده‌سازی این متد کمکی از ابتدایی‌ترین نمونه‌ها تا نسخه‌های پیشرفته‌تر برای درک بهتر مطلب نشان داده شود.
.
پیاده‌سازی متد String.format
1. در این پیاده‌سازی از اولین فرایندی که ممکن است به ذهن یک برنامه‌نویس خطور کند استفاده شده است. این پیاده‌سازی بسیار ساده به صورت زیر است:
String.format = function () {
var s = arguments[0];
for (var i = 0; i < arguments.length - 1; i++) {
s = s.replace("{" + i + "}", arguments[i + 1]);
}
return s;
};.
2. پیاده‌سازی مشابهی هم با استفاده از نوع دیگری از حلقه for که تقریبا! مشابه با حلقه foreach در #C است به صورت زیر می‌توان درنظر گرفت:
String.format = function () {
var s = arguments[0];
for (var arg in arguments) {
var i = parseInt(arg);
s = s.replace("{" + i + "}", arguments[i + 1]);
}
return s;
};در این متدها ابتدا فرمت واردشده توسط کاربر از لیست آرگومان‌های متد خوانده شده و در متغیر s ذخیره می‌شود. سپس درون یک حلقه به ازای هر توکن موجود در رشته فرمت، یک عملیات replace با مقدار متناظر در لیست آرگومان‌های متد انجام می‌شود. نحوه استفاده از این متد نیز به صورت زیر است:
console.log(String.format("{0} is nice!", "donettips.info"));هر دو متد خروجی یکسانی دارند، به صورت زیر:
donettips.info is nice!
تا اینجا به نظر می‌رسد که عملیات به‌درستی پیش می‌رود. اما اولین و بزرگ‌ترین مشکل در این دو متد نحوه کارکردن متد replace در جاوا اسکریپت است. این متد با این نحوه فراخوانی تنها اولین توکن موجود را یافته و عملیات جایگزینی را برای آن انجام می‌دهد. برای روشن‌تر شدن موضوع به مثال زیر توجه کنید:
console.log(String.format("{0} is {1} nice! {0} is {1} nice!", "donettips.info", "very"));donettips.info is very nice! {0} is {1} nice!.
3. برای حل مشکل فوق می‌توان از روش ساده زیر استفاده کرد:
String.format = function () {
var original = arguments[0],
replaced;
for (var i = 0; i < arguments.length - 1; i++) {
replaced = '';
while (replaced != original) {
original = replaced || original;
replaced = original.replace("{" + i + "}", arguments[i + 1]);
}
}
return replaced;
};donettips.info is very nice! donettips.info is very nice!
.
4. راه حل دیگر استفاده از امکانات شی RegExp در دستور replace است. نکته مهم استفاده از modifier کلی یا global (که با حرف g مشخص می‌شود) در شی تولیدی از RegExp است (^ و ^ و ^، برای جلوگیری از دورشدن از بحث اصلی، جستجو برای کسب اطلاعات بیشتر در این زمینه به خوانندگان واگذار می‌شود). برای استفاده از این شی متد ما به صورت زیر تغییر میکند:
String.format = function () {
var s = arguments[0];
for (var i = 0; i < arguments.length - 1; i++) {
s = s.replace(new RegExp("\\{" + i + "\\}", "g"), arguments[i + 1]);
}
return s;
};.
5. روش دیگری که کمی از دو متد قبلی سریع‌تر اجرا می‌شود (به دلیل استفاده از حلقه while) به صورت زیر است:
String.format = function () {
var s = arguments[0],
i = arguments.length - 1;
while (i--) {
s = s.replace(new RegExp('\\{' + i + '\\}', 'g'), arguments[i + 1]);
}
return s;
};console.log(String.format("{0}:0 {1}:1 {2}:2", "zero", "{2}", "two"));zero:0 {2}:1 two:2zero:0 two:1 two:2
console.log(String.format("{0}:0 {1}:1 {2}:2", "zero", "one", "{1}"));zero:0 one:1 one:2
zero:0 one:1 {1}:2.
6. برای حل مشکل بالا نیز می‌توان از یکی دیگر از امکانات دستور replace استفاده کرد که به صورت زیر است:
String.format = function () {
var args = arguments;
return args[0].replace(/{(\d+)}/g, function (match, number) { return args[parseInt(number) + 1]; });
};در اینجا از قابلیت سفارشی‌سازی عملیات جایگزینی در دستور replace استفاده شده است. با استفاده از این ویژگی عملیات replace برای هر توکن جداگانه انجام می‌شود و بنابراین تغییرات اعمالی در حین عملیات تاثیر مستقیمی برای ادامه روند نخواهد گذاشت.
دقت کنید که برای بکاربردن RegExp درون دستور replace به جای تولید یک نمونه از شی RegExp می‌توان عبارت مربوطه را نیز مستقیما بکار برد. در اینجا از عبارتی کلی برای دریافت تمامی توکن‌های با فرمتی به صورت {عدد} استفاده شده است.
متد سفارشی مربوطه نیز شماره ردیف توکن یافته‌شده به همراه خود عبارت یافته‌شده را به عنوان آرگومان ورودی دریافت کرده و مقدار متناظر را از لیست آرگومان‌های متد اصلی پس از تبدیل شماره ردیف توکن به یک عدد، برگشت می‌دهد (در اینجا نیز برای جلوگیری از دورشدن از بحث اصلی، جستجو برای کسب اطلاعات بیشتر در این زمینه به خوانندگان واگذار می‌شود).
برای جلوگیری از تداخل بین آرگومان‌های متد اصلی و متد تهیه‌شده برای سفارشی‌سازی عملیات جایگزینی، در ایتدای متد اصلی، لیست آرگومان‌های آن درون متغیر جداگانه‌ای (args) ذخیره شده است.
با استفاده از این متد خروجی درست نشان داده می‌شود. حال مثال زیر را درنظر بگیرید:
console.log(String.format("{0} is {1} nice!", "donettips.info"));donettips.info is undefined nice!
.
7. برای کنترل بیشتر و رفع خطاهای احتمالی در متد بالا، می‌توان ابتدا از وجود آرگومان مربوطه در متغیر args اطمینان حاصل کرد تا از جایگزینی مقدار undefined در رشته نهایی جلوگیری کرد. مانند نمونه زیر:
String.format = function () {
var s = arguments[0],
args = arguments;
return s.replace(/{(\d+)}/g, function (match, number) {
var i = parseInt(number);
return typeof args[i + 1] != 'undefined' ? args[i + 1] : match;
});
};در فرمت بندی رشته‌ها برای نمایش خود کاراکتر { یا } از تکرار آنها (یعنی {{ یا }}) استفاده می‌شود. اما متد ما تا این لحظه این امکان را ندارد. برای مثال:
console.log(String.format("{0}:0 {1}:1 {2}:2, {{0}} {{{1}}} {{{{2}}}} {2}", "zero", "{2}", "two"));zero:0 {2}:1 two:2, {zero} {{{2}}} {{{two}}} two8. برای پیاده‌سازی امکان اشاره‌شده در بالا می‌توان از کد زیر استفاده کرد:
String.format = function () {
var s = arguments[0],
args = arguments;
return s.replace(/\{\{|\}\}|\{(\d+)\}/g, function (match, number) {
if (match == "{{") { return "{"; }
if (match == "}}") { return "}"; }
var i = parseInt(number);
return typeof args[i + 1] != 'undefined'
? args[i + 1]
: match;
});
};این متد خروجی صحیح زیر را برای مثال آخر ارائه می‌دهد:
zero:0 {2}:1 two:2, {0} {{2}} {{2}} twoپیاده‌سازی به‌صورت یک خاصیت prototype
تمامی متدهای نشان داده‌شده تا اینجا به‌صورت مستقیم از طریق String.format در دسترس خواهند بود (تعریفی شبیه به متدهای استاتیک در دات نت). درصورتی‌که بخواهیم از این متدها به صورت یک خاصیت prototype شی string استفاده کنیم (چیزی شبیه به متدهای instance در اشیای دات نت) میتوانیم از تعریف زیر استفاده کنیم:
String.prototype.format = function () {
...
}تنها فرق مهم این پیاده‌سازی این است که رشته مربوط به فرمت وارده در این متد از طریق شی this در دسترس است و بنابراین شماره اندیس آرگومان‌های متد یکی کمتر از متدهای قبلی است که باید مدنظر قرار گیرد. مثلا برای متد آخر خواهیم داشت:
String.prototype.format = function () {
var s = this.toString(),
args = arguments;
return s.replace(/\{\{|\}\}|\{(\d+)\}/g, function (match, number) {
if (match == "{{") { return "{"; }
if (match == "}}") { return "}"; }
return typeof args[number] != 'undefined'
? args[number]
: match;
});
};نکته: در تمامی خواص prototype هر شی در جاوا اسکریپت، متغیر this از نوع object است. بنابراین برای جلوگیری از وقوع هر خطا بهتر است ابتدا آنرا به نوع مناسب تبدیل کرد. مثل استفاده از متد toString در متد فوق که موجب تبدیل آن به رشته می‌شود.
.
ازآنجاکه نیاز به تغییر اندیس در متد سفارشی عملیات replace وجود ندارد، بنابراین خط مربوط به تبدیل آرگومان number به یک مقدار عددی (با دستور parseInt) حذف شده است و از این متغیر به صورت مستقیم استفاده شده است. در این حالت عملیات تبدیل توسط خود جاوا اسکریپت مدیریت می‌شود که کار را راحت‌تر می‌سازد.
بنابراین متد ما به صورت زیر قابل استفاده است:console.log("{0}:0 {1}:1 {2}:2, {{0}} {{{1}}} {{{{2}}}} {2}".format("zero", "{2}", "two"));.
پیاده‌سازی با استفاده از توکن‌های غیرعددی
برای استفاده از توکن‌های غیرعددی میتوانیم به صورت زیر عمل کنیم:
String.format = function () {
var s = arguments[0],
args = arguments[1];
for (var arg in args) {
s = s.replace(new RegExp("{" + arg + "}", "g"), args[arg]);
}
return s;
};String.prototype.format = function () {
var s = this.toString(),
args = arguments[0];
for (var arg in args) {
s = s.replace(new RegExp("{" + arg + "}", "g"), args[arg]);
}
return s;
};با استفاده از این دو متد داریم:
console.log(String.format("{site} is {adj}! {site} is {adj}!", { site: "donettips.info", adj: "nice" }));
console.log("{site} is {adj}! {site} is {adj}!".format({ site: "donettips.info", adj: "nice" }));.
تا اینجا متدهایی نسبتا کامل برای نیازهای عادی برنامه‌نویسی تهیه شده است. البته کار توسعه این متد برای پشتیبانی از امکانات پیشرفته‌تر فرمت‌بندی رشته‌ها می‌تواند ادامه پیدا کند.
.
کتابخانه‌های موجود
یکی از کامل‌ترین کتابخانه‌های کار با رشته‌ها همان کتابخانه معروف Microsoft Ajax Client Libray است که بیشتر امکانات موجود کار با رشته‌ها در دات نت را در خود دارد. صرفا جهت آشنایی، پیاده‌سازی متد String.format در این کتابخانه در زیر آورده شده است:
String.format = function String$format(format, args) {
/// <summary locid="M:J#String.format" />
/// <param name="format" type="String"></param>
/// <param name="args" parameterArray="true" mayBeNull="true"></param>
/// <returns type="String"></returns>
// var e = Function._validateParams(arguments, [
// { name: "format", type: String },
// { name: "args", mayBeNull: true, parameterArray: true }
// ]);
// if (e) throw e;
return String._toFormattedString(false, arguments);
};
String._toFormattedString = function String$_toFormattedString(useLocale, args) {
var result = '';
var format = args[0];
for (var i = 0; ; ) {
var open = format.indexOf('{', i);
var close = format.indexOf('}', i);
if ((open < 0) && (close < 0)) {
result += format.slice(i);
break;
}
if ((close > 0) && ((close < open) || (open < 0))) {
if (format.charAt(close + 1) !== '}') {
throw Error.argument('format', Sys.Res.stringFormatBraceMismatch);
}
result += format.slice(i, close + 1);
i = close + 2;
continue;
}
result += format.slice(i, open);
i = open + 1;
if (format.charAt(i) === '{') {
result += '{';
i++;
continue;
}
if (close < 0) throw Error.argument('format', Sys.Res.stringFormatBraceMismatch);
var brace = format.substring(i, close);
var colonIndex = brace.indexOf(':');
var argNumber = parseInt((colonIndex < 0) ? brace : brace.substring(0, colonIndex), 10) + 1;
if (isNaN(argNumber)) throw Error.argument('format', Sys.Res.stringFormatInvalid);
var argFormat = (colonIndex < 0) ? '' : brace.substring(colonIndex + 1);
var arg = args[argNumber];
if (typeof (arg) === "undefined" || arg === null) {
arg = '';
}
if (arg.toFormattedString) {
result += arg.toFormattedString(argFormat);
}
else if (useLocale && arg.localeFormat) {
result += arg.localeFormat(argFormat);
}
else if (arg.format) {
result += arg.format(argFormat);
}
else
result += arg.toString();
i = close + 1;
}
return result;
}console.log(String.format("{0:n}, {0:c}, {0:p}, {0:d}", 100.0001));
// result: 100.00, ¤100.00, 10,000.01 %, 100.0001
console.log(String.format("{0:d}, {0:t}", new Date(2015, 1, 1, 10, 45)));
// result: 02/01/2015, 10:45آخرین نسخه این کتابخانه از اینجا قابل دریافت است (این متدها درون فایل MicrosoftAjax.debug.js قرار دارند). این کتابخانه دیگر به این صورت و با این نام توسعه داده نمیشود و چند سالی است که تصمیم به توسعه ویژگی‌های جدید آن به صورت پلاگین‌های jQuery گرفته شده است.
.
کتابخانه دیگری که می‌توان برای عملیات فرمت‌بندی رشته‌ها در جاوا اسکریپت از آن استفاده کرد، کتابخانه معروف jQuery Validation است. این کتابخانه یک متد نسبتا خوب با نام format برای فرمت کردن رشته‌ها دارد. نحوه استفاده از این متد به صورت زیر است:
var template = jQuery.validator.format("{0} is not a valid value");
console.log(template("abc"));
// result: 'abc is not a valid value'.
کتابخانه نسبتا کامل دیگری که وجود دارد، با عنوان Stringformat از اینجا قابل دریافت است. برای استفاده از این کتابخانه باید به صورت زیر عمل کرد:
String.format([full format string], [arguments...]); // or: [date|number].format([partial format string]);
// Object path
String.format("Welcome back, {username}!",
{ id: 3, username: "JohnDoe" });
// Result: "Welcome back, JohnDoe!"
// Date/time formatting
String.format("The time is now {0:t}.",
new Date(2009, 5, 1, 13, 22));
// Result: "The time is now 01:22 PM."
// Date/time formatting (without using a full format string)
var d = new Date();
d.format("hh:mm:ss tt");
// Result: "02:28:06 PM"
// Custom number format string
String.format("Please call me at {0:+##0 (0) 000-00 00}.", 4601111111);
// Result: "Please call me at +46 (0) 111-11 11."
// Another custom number format string
String.format("The last year result was {0:+$#,0.00;-$#,0.00;0}.", -5543.346);
// Result: "The last year result was -$5,543.35."
// Alignment
String.format("|{0,10:PI=0.00}|", Math.PI);
// Result: "| PI=3.14|"
// Rounding
String.format("1/3 ~ {0:0.00}", 1/3);
// Result: "1/3 ~ 0.33"
// Boolean values
String.format("{0:true;;false}", 0);
// Result: "false"
// Explicitly specified localization
// (note that you have to include the .js file for used cultures)
msf.setCulture("en-US");
String.format("{0:#,0.0}", 3641.667);
// Result: "3,641.7"
msf.setCulture("sv-SE");
String.format("{0:#,0.0}", 3641.667);
// Result: "3 641,7".
یک کتابخانه دیگر نیز از این آدرس قابل دریافت است. این کتابخانه با عنوان String.format نام‌گذاری شده است. نحوه استفاده از این کتابخانه نیز به صورت زیر است:
//inline arguments
String.format("some string with {0} and {1} injected using argument {{number}}", 'first value', 'second value');
//returns: 'some string with first value and second value injected argument {number}'
//single array
String.format("some string with {0} and {1} injected using array {{number}}", [ 'first value', 'second value' ]);
//returns: 'some string with first value and second value injected using array {number}'
//single object
String.format("some string with {first} and {second} value injected using {{propertyName}}",{first:'first value',second:'second value'});
//returns: 'some string with first value and second value injected using {propertyName}'کتابخانه نسبتا معروف و کامل sprintf نیز در اینجا وجود دارد. این کتابخانه امکانات بسیاری همچون متدهای متناظر در زبان C دارد.
.
منابع