I wrote about my plans to add a new SQL parser engine into dbscript a couple of months ago. Now the time has come to actually implement it for T-SQL (MS SQL Server; Oracle and PostgreSQL will follow in future versions), and I found that I did not foresee all the consequences of my initial intent. The overall architecture remained the same though.

The grammar definition allows to define attributes on non-terminals. Using the SQL Server versions as attributes (2005, 2008), I can mark commands or clauses as their support or feature has been introduced in a specific version, and store the database version as property of the uploaded Project Version.

The parser skips the parts of the uploaded file that it cannot parse, and writes these parts to the upload log. Up to now, the parser would simply fail if it considered the SQL file somehow invalid.

The (C#) object representation of a parsed SQL command has a boolean flag IsHandled for each non-terminal. The code processing the object representation needs to mark every non-terminal object as being handled (i.e. translated into schema information stored in the database). Objects that have not been flagged will also be listed in the upload log.

Next, the new parser allowed me to rewrite the dependency analysis. Until now, dbscript only analyzed view dependencies to order the CREATE VIEW statements. Dependency analysis has now been extended to all database objects.

One more major issue that has been solved is parsing and interpreting EXECUTE statements. Thus an EXEC sp_addextendedproperty is interpreted as adding a description to a database object.

This obviously led to changes in the XML generation of database schemas. Each object now lists its descriptions and the dependencies on and references from other database objects.

The XSL stylesheets which translate a project version XML into markup or HTML have been revised to reflect the additional information in the generated XML.

All taken together, the new parser adds:

• better feedback on which parts of the uploaded SQL file have been processed
• dependency analysis
• object and column descriptions

See the following links documenting AdventureWorks OLTP 2008 (version 2005) for the effects of the new functionality:

Single HTML file documentation

MediaWiki documentation

ScrewTurn Wiki documentation

In both wikis, compare the (old-style) “wikibot” section with the new section “automatically generated” to see the changes.

The next version of dbscript with the mythical version number “1.0″ will be released soon

Chalutations,

Suite à mon billet “Personnalisons Wikipédia : le sommaire“, je lance un mini-concours de personnalisations : il n’y a rien à gagner, si ce n’est le plaisir de partager son code et de le voir réutilisé !

Donc, j’invite chacun à faire son propre design de sommaire, et poster dans la zone commentaire du présent billet un lien vers une capture d’écran du résultat (par exemple uploadée sur imageShack)+un lien vers votre monobook.css/vector.css. Une personne peut poster plusieurs designs, pour peu qu’ils soient notablement différents.

Le “mini concours” ouvre aujourd’hui (29 novembre) et se terminera dans 2 semaines (le 12 décembre 2009 au soir), suite à quoi je posterais une compilation de vos différentes œuvres. Je suis disponible sur IRC et ma page de discussion pour répondre à vos éventuelles questions et vous aider à débugger un peu si nécessaire.

Wikimédiens, à vos claviers !

Używając tematu MonoBook lub Książka w wersji polskiej w MediaWiki, natknąłem się na problem z wyświetlaniem panelu nawigacji. Problem występuje jeżeli używamy przeglądarki Chrome lub Chromium.

Rozwiązaniem jest edycja pliku skins/monobook/KHTMLFixes.css należy zmienić 3 linię pliku na:

/* #column-content { margin-left: 0; } */

Skrypt usuwa stare wersje (edycje) stron. Został przetestowany na MediaWiki wersja 1.15.1, przed wykonaniem skryptu zalecam wykonanie kopii zapasowej. Skrypt usuwa również historię obserwowanych stron.

delete from revision where rev_id not in (select page_latest from page);
delete from text where old_id not in (select rev_text_id from revision);
delete from recentchanges;
update revision set rev_parent_id=0;

Po wykonaniu skryptu możemy sprawdzić ilość wierszy w tabelach text, page oraz revision. Jeśli ilość wierszy w każdej z nich jest taka sama to znaczy, że wszystko poszło zgodnie z planem.

Skrypt usuwa stare wersje (edycje) stron. Został przetestowany na MediaWiki wersja 1.15.1, przed wykonaniem skryptu zalecam wykonanie kopii zapasowej.

delete from revision where rev_id not in (select page_latest from page);
delete from text where old_id not in (select rev_text_id from revision);
update revision set rev_parent_id=0;

Po wykonaniu skryptu możemy sprawdzić ilość wierszy w tabelach text, page oraz revision. Jeśli ilość wierszy w każdej z nich jest taka sama to znaczy, że wszystko poszło zgodnie z planem.

When a Muppet retires, he may go to the Jim Henson Company Archives. He may not merely report to the archives in puppet form, though—he may show up as an animation cell or even a sketch by Jim Henson himself. Cookie Monster, Elmo and Kermit will be preserved for future generations of Sesame Street viewers—and for those of us who enjoy the reruns.

The archives are now in turn preserved—or at least described— on a wiki, http://muppet.wikia.com/wiki/The_Jim_Henson_Company_Archives.

While the wiki doesn’t necessarily present the archives as being especially innovative, the MediaWiki itself is worth considering as a point of discussion. Originally for use on Wikipedia, MW is open-source PHP (briefly, Web-development scripting language) software. Wikia.com has utilized the software, via a free content license, to develop a wiki site to be used by “millions of passionate fans.” While the Jim Henson Company Archive entry seems to be accurate and informed, the banner ads surrounding the wiki entry are off-putting. Is it right to profit from open-source software? If it is, by how much? Non-profits developing software utilized by for-profit companies?

External Data se trata de una extensión para Semantic MediaWiki que nos proporciona la capacidad de obtener, filtrar y dar formato a datos externos para la inclusión en un artículo. Se definen 5 funciones parseadoras:

• #get_external_data para obtener datos CSV, XML o JSON desde una URL, y asignarlos a variables que pueden ser accesibles en la página
• #get_db_data para obtener datos de una BBDD relacional
• #get_ldap_data para obtener datos de un servidor LDAP
• #external_value para mostrar el valor de esos datos
• #for_external_table recorre todos los valores obtenidos para un juego de variables, mostrando el mismo contenedor para cada una de ellas

Obtención de datos de una URL mediante CSV, XML o JSON

En caso de que vayamos contra una API cuya salida se ajusta a una de estas 3 mencionadas, llamaremos a la siguiente función:

{{#get_external_data:URL|format|external_variable_name1==filter_value1|...|local_variable_name2=external_variable_name2|...}}

• URL es la ruta del fichero CSV, XML o JSON
• format es ‘XML’, ‘CSV’, ‘CSV with header’ o ‘JSON’
• los parámetros con un ‘==‘ son filtros; hacen un filtrado sobre las “filas” devueltas. Lo normal es que la API contra la que vayamos ya tenga filtrado gracias a los parámetros de la URL.
• los parámetros con un ‘=‘ son mapeados; permiten conectar variables externas  a variables locales. Las variables externas son los nombres de los valores en el fichero. Las variables locales son las que se pasarán más tarde a la función #external_value

Se pueden hacer varias llamadas a esta función en una misma pagina; sólo tenemos que tener cuidado eligiendo nombres distintos para las variables locales.

Podemos reemplazar un string en la URL, por ejemplo para esconder la clave de acceso a la API. Para ello, escribiremos una línea como la siguiente en LocalSettings:

$edgStringReplacements['FLICKR_KEY'] = '9fh349f7yhwiye';

y en el artículo escribiremos FLICKR_KEY, sustituyéndose a posteriori por la clave.

Mostrando los datos

Una vez  hemos obtenido los datos, existen dos maneras de mostrarlos: #external_values y #for_external_table:

1) Mostrar datos individualmente

Tan sencillo como llamar a la primera función:

{{#external_value:local_variable_name}}

2) Mostrar una tabla de valores

Los datos obtenidos mediante #get_external_data pueden tener varios valores por campo, por lo que nos gustaría mostrarlos como una tabla. Para ello escribimos lo siguiente:

{{#for_external_table:expression}}

donde expression se trata de un string conteniendo las variables que queremos entre triples llaves. Por ejemplo:

{|
! Name
! Borders
! Population
! Area {{#for_external_table:<nowiki/>
{{!}}-
{{!}} {{{name}}}
{{!}} {{{borders}}}
{{!}} {{{population}}}
{{!}} {{{area}}} }}
|}

Extras

• Podemos hacer que los datos obtenidos remotamente se conviertan en datos semánticos, y además que esos datos se puedan actualizar si la fuente cambia, con una simple tarea cron.
• Podemos limitar las URLs contra las que se puede ir creando una Whitelist

Más información sobre todo esto a continuación.

Fuente: http://www.mediawiki.org/wiki/Extension:External_Data

Ce billet fait partie de la série “Personnalisons Wikipédia“. La personnalisation du jour vous permettra de rendre toutes ces pages trop sérieuses un poil plus rigolotes (ou pas) en modifiant la tronche de leur sommaire à l’aide de quelques lignes de CSS.

Comme d’habitude, le code est à insérer dans votre sous page /monobook.css, ou /vector.css selon le skin MediaWiki  que vous utilisez.

Partie HTML

Le code d’un sommaire ressemble à ça (l’exemple est pris sur la page du bulletin des admins, pour les titres de section) :

<table id="toc" class="toc">
[...]
<ul>
	<li class="toclevel-1 tocsection-1">
		<a href="#(semaine)"><span class="tocnumber">(numérotation)</span> <span class="toctext">(semaine)</span></a>
		<ul>
			<li class="toclevel-2 tocsection-2">
				[..lien section jour, identique a celui des semaines ci dessus..]
				<ul>
					<li class="toclevel-3 tocsection-3">[..lien section titre..]</li>
					<li class="toclevel-3 tocsection-4 ">[..lien section titre..]</li>
					<li class="toclevel-3 tocsection-5">[..lien section titre..]</li>
				</ul>
			</li>
			<li class="toclevel-2 tocsection-6">
				[..lien section jour..]
				<ul>
					<li class="toclevel-3 tocsection-7">[..lien section titre..]</li>
					<li class="toclevel-3 tocsection-8">[..lien section titre..]</li>
				</ul>
			</li>
			[...]
		</ul>
	</li>
</ul>
</table>

Les deux choses importantes à retenir sont :

• Chaque niveau du sommaire à une classe dédiée (toclevel-X ). C’est là dessus que se basera notre code CSS.

• Les niveaux sont imbriqués (niveau 2 contenu dans le 1, 3 dans le 2, etc), ce qui signifie que si on ne précise pas le contraire, un code affecté au niveau 2 affectera par défaut tous les niveaux 3 à 6  qu’il contient

Le code CSS

Vous connaissez déjà le gros de la syntaxe utilisée car elle a déjà été expliquée dans mes précédents billets (si vous ne les avez pas lu, c’est le moment . Les quelques éléments nouveaux seront détaillés en /* commentaires */ dans le code.

Le bout de code ci dessous donnera un style “météo” à l’ensemble des sommaires. J’expliquerais plus bas comment limiter son action à seulement certains d’entre eux (par exemple, uniquement le bistro, ou uniquement l’espace wikipédia: )

Initialement, je comptais faire un style plus ensoleillé… mais pas moyen de trouver une icone potable de chapeaux mexicains. Donc tant pis, les icones météo feront l’affaire. De toute manière, ça n’est qu’un exemple, le but étant que vous ayez la curiosité de modifier/adapter  le code à votre sauce ensuite (soyons fous et optimistes…)

/* sommaires, "météo mode"
   les modifications sont faites sur le lien (a) plutôt que sur la ligne (li) afin que l'icône soit cliquable.
 */

/* effacer la numérotation du sommaire, car elle va m'embêter pour la suite */
.tocnumber {
	display:none;
}

/* grande font, bleu foncé, avec un soleil à gauche */
.toclevel-1 a {
	color:#007;
	font-size:160%;

	background:transparent url('http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Crystal_sun.png/25px-Crystal_sun.png') no-repeat scroll left bottom;
	padding-left:29px; /* décaler le texte sur la droite pour laisser de la place a l'icône */
}

/* font un peu moins grande, bleu standard, icône nuageuse à sa gauche */
.toclevel-2 a {
	font-size:130%;
	color:#00F;

	background:transparent url('http://upload.wikimedia.org/wikipedia/commons/thumb/7/72/Cloudy01.svg/20px-Cloudy01.svg.png') no-repeat scroll left bottom;
	padding-left:24px;
}

/* font taille normal, bleu plus clair, icône orage */
.toclevel-3 a {
	font-size:100%;
	color:#55F;

	background:transparent url('http://upload.wikimedia.org/wikipedia/commons/c/cf/Weather_lightning.png') no-repeat scroll left bottom;
	padding-left:19px;
}

/* font plus petite, bleu encore un peu plus clair, pas d'icône (car serait trop petite pour être reconnaissable) */
.toclevel-4 a {
	font-size:80%;
	color:#99F;

	background:none; /* pas d'image de fond (l'icône sur la gauche), il faut le spécifier sinon celle du niveau 3 s'affichera */
	/* je laisse le padding-left hérité du niveau supérieur pour que le décalage soit cohérent avec les niveaux d'au dessus */}

Le résultat

Pour vous donner une meilleure idée de l’impact, j’ai aussi fait une capture des sommaires du BA et du bistro avec ce thème, c’est cliquable et c’est ci dessous. Moins lugubre tout de suite, non ?

Limiter la portée du code

Maintenant, vous n’avez probablement pas envie que ce code soit actif sur absolument toutes les pages, et souhaitez le limiter a un/des namespace(s) ou des pages en particuliers.

Je veux dire, ce style rend bien pour les pages qui ont une arborescence sur plusieurs niveaux, mais pour une page ou ça n’est pas le cas, ça ressemble plutôt à ça, que je trouve moche :

Pour ce faire, nous allons nous servir d’une série de classes que MediaWiki affecte à chaque page. Par exemple, le Bulletin des administrateurs (avec ma config) possède celles ci :

<body class="mediawiki ltr ns-4 ns-subject page-Wikipédia_Bulletin_des_administrateurs skin-monobook">

(je saute celles que je ne connais/comprend pas)

• “ltr” indique que nous sommes dans un mode “left to right” (en opposition, par exemple, à l’arabe qui se lis en rtl, de droite à gauche)

• “ns-4” est l’identifiant du namespace de la page (ici wikipédia: )

• “page-Wikipédia_Bulletin_des_administrateurs” est un identifiant unique (ou presque) de la page

• “skin-monobook“, comme son nom l’indique, spécifie que j’utilise le skin “monobook” pour visualiser la page. Les utilisateurs d’Açai/Babaco verront à la place “skin-vector“.

Les deux qui nous intéressent sont celui qui indique le namespace et celui qui est unique à la page.

Mettons que je veuille limiter la portée du code au namespace wikipédia: . Au lieu de

.toclevel-1 a {

il suffit de mettre

.ns-4 .toclevel-1 a {

Et si je veux limiter sa portée au BA et au bistro, le code devient

.page-Wikipédia_Bulletin_des_administrateurs .toclevel-1 a, .page-Wikipédia_Le_Bistro .toclevel-1 a  {

Et voila le travail !

ابزارهای مدیریت محتوا باید هم راستا با استراتژی و سیاست های کلان شرکت ها باشند. از این رو پیش از انتخاب ابزار، بر رعایت سه گام اصلی تاکید می شود.

۱) تعریف و تفکیک سرویس هایی که قرار است ارائه شود؟ (Portfolio)

۲) تعریف نوع مخاطبانی که قرار است از این سرویس ها استفاده کنند؟ (Demand)

۳) هزینه تهیه و نگهداری و استفاده از سرویس های ارائه خواهد شد؟ (Finance)

در گام اول خدماتی که قرار است ارائه شود تعریف شده و چشم اندازی از ابزارهای موردنیاز ترسیم می شود. در گام دوم مشخص می شود که این خدمات برای کدام دسته از مخاطبان طراحی شده و در گام سوم تبیین می شود که هزینه عرضه و استفاده از این خدمات چگونه است؟ با رعیت گام های سه گانه فوق الذکر می توان حدود و ثغور ابزارهای فنی را مشخص کرد. همچنین بر وجود دو رویکرد متفاوت و متقابل در طراحی و تولید نرم افزارهای مدیریت محتوای متن باز و رایگان تاکید شد. اگر قرار باشد دقیق تر صحبت کنیم باید رویکردهای دوگانه را به سه رویکرد اقیانوس بی کران، چاه لایتناهی و دریاچه امن تعمیم داده و درباره مشخصات هریک به اختصار بگویم که: . رویکرد اول که اقیانوس بی کران خطاب می شود به تولید نرم افزار همه کاره توجه نشان می دهد و مشابه اقیانوسی به عمق یکی دو سانتی متر و وسعتی بی کران است. کمیت امکانات در این گونه نرم افزارها فراوان است که با قابلیت های فنی محدودی ارائه می شوند. نرم افزارهای عام راه اندازی وب سایت و پورتال مانند DotNetNuke و WebGUI و TikiWiki از این دسته اند.

رویکرد دوم که به گونه ای فانتزی چاه لایتناهی خوانده می شود، به تولید نرم افزار تخصصی اعتقاد دارد و همانند چاهی به قطر یکی دو سانتی متر و عمقی بی نهایت است. کمیت امکانات در این قبیل نرم افزارها محدود اما از بعد کیفی قابل توجه است. نرم افزارهای تخصصی وبلاگ و دانش نامه مانند MovableType و WordPress و MediaWiki از این دسته اند. . رویکرد سوم که چند سالی است مورد توجه قرار گرفته، دریاچه امن خوانده می شود و گرته برداری هوشمندانه ای از رویکردهای دوگانه قبلی است، بدین صورت که اعتقادی به ارائه امکانات کیفی لایتناهی و امکانات کمی بی کران نداشته و بر ایجاد تعادل در امکانات منتخب تاکید دارد. به طور خلاصه می توان گفت که رویکرد دریاچه امن بر ارائه بهنیه امکانات اصرار می کند. نرم افزارهای مبتنی بر این رویکرد از یک سو امکانات قابل توجهی دارد و از دیگرسو قدری هم وارد لایه های تخصصی می شود. نرم افزارهای Drupal و Plone بهترین نمونه های تولید شده با رویکرد بهینه هستند.

● هزینه مالکیت نهایی

تب استفاده از فرآورده های جنبش متن باز و رایگان چنان بیداد می کند که توجه به زیر و زبر کار در این هیاهو اغلب فراموش می شود. انتخاب نرم افزارهای متن باز اغلب براساس تصور نادرست کاهش هزینه ها صورت می گیرد. اصطلاح Total Cost of Ownership در میان زعمای وادی فناوری اطلاعات بسیار مورد استفاده قرار دارد و به مجموع هزینه هایی اطلاق می شود که از ابتدای تعریف خدمات تا پایان آن باید صرف شود. موسسه گارتنر نشان داده که تعریف انواع خدمات نیازمند گرد آمدن دانش و ابزارهای سخت افزاری و نرم افزاری و مدیریت و پشیبانی و غیره است. در این میان ۷۰ درصد هزینه ارائه خدمات صرف ارائه خدمات پشتیبانی شده و تنها ۶ درصد هزینه صرف تهیه نرم افزار می شود. سخت افزار حدود ۱۵ درصد و پیاده سازی شبکه حدود ۲ درصد از کل هزینه خدمات را صرف می کنند. حدود ۷ درصد از کل هزینه نیز به علت عدم دسترسی خدمات تلف می شود. براین اساس می توان گفت که استفاده از نرم افزارهای متن باز در بهترین حالت کمتر از یک بیستم در هزینه کل صرفه جویی خواهد کرد. موضوع ارائه خدمات کیفی پشتیبانی جایگاه ویژه ای در برنامه ریزی های اغلب سازمان های ایرانی که وظف به ارائه خدمات الکترونیک هستند ندارد. خلاصه این که درآمد اصلی اغلب شرکت های حاضر در وادی فناوری اطلاعات و ارتباطات از بطن خدمات حاصل می شود.

● آیا مدیریت محتوا ضرورت دارد؟

بعضی سازمان ها نیازی به استفاده از نرم افزار مدیریت محتوا نمی بینند و صرف داشتن آدرسی اینترنتی (URL) و یکی دو صفحه ثابت (html) که آدرس و تلفن تماس با سازمان در آن لحاظ شده باشد را کافی می دانند. اما اگر بیش از یکی دو مرتبه در ماه نیاز به تغییر محتوا یا انتشار محتوای جدید دارید، اگر وجود بلاگ در وب سایت شما ضرورت دارد، اگر می خواهید تغییرات را به طور مستقیم و بدون دخالت برنامه نویسان در محتوای وب سایت اعمال کنید، اگر می خواهید که وابستگی جغرافیایی به وب سایت نداشته باشید و از هر نقطه آن را مدیریت کنید و اگر می خواهید که وب سایت شما به سهولت توسط سیستم های جستجو مانند یاهو و گوگل شناسایی شوند، ناگزیر به استفاده از نرم افزار مدیریت محتوا هستید، در غیر این صورت همان صفحات ثابت برای شما کفایت خواهد کرد.

● از منظرهای مختلف

انتخاب نرم افزار مدیریت محتوا را از منظرهای مختلف می توان بررسی کرد. به عنوان مثال می توان چند نکته را مورد توجه قرار داد و نرم افزارهای متعدد را با آن فیلتر کرد، یا فهرستی از قابلیت های خاص را تهیه و انطباق قابلیت های مختلف نرم افزارهای گوناگون را با آن بررسی کرد. توصیه می کنیم که از هر دو منظر به موضوع انتخاب بهینه نرم افزار مدیریت محتوا نگریسته شود تا انتخابی جامع و مانع صورت گیرد.

● انتخاب از منظر نکته های کلیدی

▪ اول؛ به طور عمومی این گونه تصور می شود که تمام نرم افزارهای مدیریت محتوا برای تولید، تغییر، انتشار و نگهداری محتوا به کار می روند و کار دیگری برای انجام ندارند. کارکرد اصلی نرم افزارها و شیوه مدیریت محتوا را در همین قدم باید زیر ذره بین قرار داد. به عنوان مثال نرم افزار WordPress برای ایجاد وبلاگ شخصی و خرده وب سایت ها استفاده می شود. از Drupal و Plone برای ایجاد وب سایت های بزرگ و متعدد استفاده می شود. همچنین باید در شیوه مدیریت محتوا نیز دقیق شد. برخی از نرم افزارهای ایجاد وبلاگ اجازه تعریف صفحه نمی دهند و تمام کارها را به صورت خودکار (هوشمند) انجام می دهند.

▪ دوم؛ کار با محتوا به شکل ذاتی با امکانی به نام ویرایشگر گره خورده است. ویرایشگر بخشی از نرم افزار محسوب می شود که بین کاربر و نرم افزار قرار گرفته و دریچه ای است که محتوا را از کاربر دریافت کرده یا برای ایجاد تغییر در اختیار کاربر قرار می دهد. برخی از نرم افزارها از ویرایشگرهای ضعیف استفاده می کنند که امکانات مختصری دارند. برخی دیگر این ضعف را با امکان افزودن نرم افزارهای ویرایشگر مرتفع ساخته اند. ویرایشگر مطلوب باید از دسته ویرایشگرهای WYSIWYG باشد. البته این گونه از ویرایشگرها با امکاناتی همراه هستند که کمتر مورد استفاده قرار می گیرند.

اگر به ویرایشگرهای ساده نیاز دارید، از انواع WYSIWYG صرف نظر کنید. در ضمن WYSIWYG مخفف عبارتی است که ترجمه اش می شود محتوا به همان صورتی نمایش داده می شود که وارد ویرایشگر شده است.

▪ سوم؛ این مورد را به دقت مورد بررسی قرار دهید که آیا نرم افزار مورد نظر شما امکان مدیریت منابع محتوایی دیگر مانند انواع فایل و تصاویر را مهیا کرده است یا خیر. اغلب نرم افزارهای مدیریت محتوا از این مشکل رنج می برند و امکانات مناسبی عرضه نمی کنند. در ضمن به غنای امکانات مدیریتی تصاویر دقت و شیوه های علامت گذاری فایل ها بیشتری داشته باشید.

▪ چهارم؛ امکان جستجو از جنس امکانات حیاتی سیستم هاست. بیشتر کاربران، وب سایت ها را از طریق وب سایت های جستجو پیدا می کنند. غنای امکانات جستجو تضمین می کند که وب سایت به سهولت قابل دسترس است. اغلب نرم افزارهای مدیریت محتوا شامل بخشی ذیل عنوان مدیریت جستجو (Search management) هستند، اما کیفیت در موارد مختلف متفاوت است. منابع متعددی در این باره صحبت کرده اند و استفاده از آنها اکیدا توصیه می شود. شک نکنید که امکان جستجوی اغلب نرم افزارهای مدیریت محتوا برای فعالیت های جدی کفایت نمی کند.

▪ پنجم؛ این نکته بدیهی را به خاطر بسپارید که تکنولوژی نرم افزاری نباید شیوه نمایش محتوا را مشخص کند، بلکه چگونگی نمایش محتوا باید به طور کامل توسط کاربر مدیریت شود. ارائه چنین امکانی به معماری نرم افزار بستگی دارد. بسیاری از نرم افزارهای کنونی از معماری MVC پیروی می کنند که محتوا در لایه ای مستقل (Content) نگهداری می شود و در لایه ای دیگر نمایش (Design) داده می شود. برنامه نویسانی که به تجربه های موفق دیگران وقعی نمی نهند و بر شیوه نه چندان موثر خود اصرار می ورزند کم نیستند و باید از این دست نرم افزارها اجتناب کرد.

▪ ششم؛ استراتژی سازمانی و سیاست شرکت ها جایگاه مخاطب را مشخص می کند.

چنانچه این امر از موارد ضروری قلمداد شود، باید از نرم افزارهایی بهره برد که امکان گردآوری و دسته بندی نظرات کاربران را فراهم سازند. اغلب نرم افزارها امکاناتی در این باره عرضه می کنند که برای امور ساده کفایت می کند. در کاربری های جدید باید از امکاناتی حرفه ای مدد جست که برقراری ارتباط دوطرفه با مخاطب را در اختیلر مدیریت قرار می دهد.

▪هفتم؛ اینکه حدود و ثغور اختیارات و بازه عمل کاربران مشخص شود از مهم ترین ویژگی های نرم افزارهای فاخر است. غنای این امکانات به کاربری وب سایت و تعداد مخاطب و کاربران پشتیبان مربوط می شود. برخی از نرم افزارها می توانند به دقت مشخص کنند که کدام کاربر، در کدام بخش ها، چه نقش هایی (Roles) دارد و مجاز (Permission) به انجام کدام کار است. حتی چگونگی انجام کارها نیز در برخی نرم افزارها قابل تعریف است. در نرم افزارهای فاخر می توان جریان محتوا (Workflow) را به طور کامل تعریف، مدیریت و حتی ارزیابی کرد.

▪ هشتم؛ اینکه بتوان به نسخه های قبلی محتوا دسترسی داشت برای برخی از افراد و سازمان ها واجد اهمیت است. این امکان اغلب با عنوان Versioning در نرم افزارهای مدیریت محتوا قرار می گیرد و استفاده از آن چندان ضرورت ندارد. بیشتر دانش نامه ها و وب سایت های خبری از طرفداران این امکان هستند.

▪ نهم؛ بسیار مشاهده شده که یک سازمان واحد نیاز به راه اندازی و مدیریت چندین وب سایت دارد و برای هر یک، از نرم افزاری مشابه و مستقل استفاده کرده است. برخی از نرم افزارهای مدیریت محتوا امکانی تحت عنوان Multiple Website دارند که به مدد آن می تواند چندین وب سایت مختلف را با دامنه های متفاوت با یک نرم افزار واحد راه اندازی و مدیریت کرد.

این امکان بیش تر مطلوب سازمان ها بود، اما افراد حقیقی نیز چندی است که از این امکان بهره می گیرند و بعید نیست که ظرف دو سه سال آینده به امکان اصلی بسیاری از نرم افزارهای مدیریت محتوا تبدیل شود.

▪ دهم؛ پشتیبانی از زبان های مختلف به اهداف مالکان نرم افزار مدیریت محتوا مربوط می شود. چنانچه قرار باشد از زبان های دیگر مانند عربی و انگلیسی و سواحیلی و اردو و اسپانیولی و پرتغالی پشتیبانی شود، همان بهتر که از نرم افزاری استفاده شود که این امکان را به صورت ذاتی در خود دارد. این قبیل نرم افزارها را در اصطلاح Multilingual خطاب می کنند. همچنین برای پشتیبانی از زبان فارسی باید نرم افزار از UTF-۸ پشتیبانی کند.

▪یازدهم؛ این که کدام یک از نکات فوق ارجحیت دارند به مراجعی مربوط می شود که قصد راه اندازی وب سایت را دارند. شاید نکته هفتم (نقش ها و مجوزها) از نکته دوم (ویرایشگر) اهمیت بالاتری داشته باشد. امنیت دسترسی ها و امکان انتخاب دستی URL برای هر مطلب و امکان تعریف Metadata برای هر مطلب و امکان دسته بندی های متنوع و پشتیبانی از RSS و پشتیبانی از CSS و تکنولوژی های توسعه و دسترسی به منابع آموزشی و موارد دیگر را نیز می توانند در زمره نکات مهم قرار داد. در بخش بعدی، فرایند انتخاب نرم افزار مدیریت محتوا را از منظری دیگر مورد بررسی قرار خواهم داد.

● انتخاب از منظر ویژگی های فنی

پیش از آغاز این بخش، ذکر این نکته لازم است که نرم افزارهای مختلف از منظر ویژگی های فنی توسط منابع و مراجع مختلف در دسته های متفاوتی قرار می گیرند که برای مخاطب عام معنادار هستند. در صورتی که مخاطب خاص می داند وضعیت فلان نرم افزار در فلان دسته بندی ضعف قلمداد می شود یا خیر.

▪ اول؛ نیازمندی های فنی (System Requirements) نرم افزار را از منظر بستر فنی مورد بررسی قرار می دهد. نوع سیستم عامل، وب سرور، پایگاه داده، مجوزها، زبان برنامه نویسی و غیره در این دسته قرار می گیرد. به طور خلاصه می توان گفت که نرم افزارهای متن باز مبتنی بر زبان برنامه نویسی PHP و پایگاه داده MySQL و وب سرور Apache در اولویت قرار دارند. برای سیستم های بزرگ استفاده از پایگاه داده شئ گرای PostgreSQL توصیه می شود. دیگر این که اغلب نرم افزارهای جدید مستقل از سیستم عامل طراحی می شوند. هر چند ثابت شده است که کارایی سیستم عامل لینوکس بالاتر است.

▪ دوم؛ امنیت (Security) از ویژگی های بسیار حیاتی است که از جنبه های مختلف در انتخاب نرم افزار تاثیر خواهد داشت. مواردی چون تصدیق هویت (Authentication) و SSL و مجوزهای دسترسی مشروط مانند Captcha و مدیریت نشست ها (Session Management) در این حوزه بررسی می شوند.

در صورت امکان توصیه می شود که مطالعه جامعی در این باره توسط کارشناسان فنی مجموعه انجام شود. این را هم بگوییم که نرم افزارهای کنونی به پشتیبانی از گونه های مختلف Authentication مانند Granular و Kerberos و LDAP و غیره اکتفا می کنند.

▪ سوم؛ پشتیبانی (Support) از موارد حائز اهمیت در انتخاب نرم افزار است. امکان دریافت خدمات حرفه ای، مشاوره، دسترسی به انواع مکتوبات، وب سایت های مرجع، کنفرانس های منطقه ای، دسترسی به مراکز داده حرفه ای طرف قرارداد با توسعه دهندگان نرم افزار و… ذیل امنیت مورد بررسی قرار می گیرند. این که بالاخره مرجعی برای رفع مشکلات وجود داشته باشد و حتی بتوان در ازای صرف هزینه مشورت دریافت کرد، برای برخی سازمان ها اهمیت دارد. این موارد کمتر برای افراد حقیقی مهم تلقی می شوند، هر چند قابل اغماض نیستند.

▪ چهارم؛ سهولت استفاده (Ease of Use) به امکاناتی اشارت دارد که تسهیل کننده مدیریت محتوا و کاربران باشند. امکان آپلود یک باره تعداد زیادی فایل (Mass Upload)، امکان ورود محتوا به صورت Drag & Drop، امکان پیش نمایش وب سایت (Prototyping)، امکان لغو دستورات (Undo)، امکان تبادل فایل های فشرده (Zip Archives)، امکان استفاده از ویرایشگر WYSIWYG، امکان تعریف آدرس های دلخواه (Friendly URLs) و امکان مدیریت کامل بر تصاویر از جمله مواردی است که موجب سهولت در استفاده از نرم افزار خواهد شد. سرعت، دقت و لذت کار با نرم افزار با استفاده از این امکانات افزایش قابل توجهی خواهد داشت.

▪ پنجم؛ کارایی (Performance) شامل موارد پیشرفته ای چون نگهداری موقت محتوا برای درخواست های متعدد (AdvancedCaching)، امکان تبادل غیرهمزمان داده میان پایگاه داده ها (Replication) و امکان مدیریت درخواست میان سرورهای مختلف (Load Balancing) می شود. این گونه امکانات اغلب مورد استفاده وب سایت های بزرگ قرار گرفته و برای منابع محتوایی محدود اهمیت ندارد.

▪ ششم؛ ابزارهای مدیریتی (Management Tools) که به طور کامل در اختیار مدیریت مجموعه قرار می گیرد و از موارد فوق العاده مهم در انجام بهینه مدیریت محسوب می شود. مدیریت تبلیغات، مدیریت منابع محتوایی مانند تصاویر و فایل های متنوع، مدیریت دسترسی به بخش های مهم، مدیریت چند وب سایت ذیل یک نرم افزار، مدیریت محتوای اضافی، مدیریت آمارها، مدیریت جریان کاری مجموعه و مدیریت قالب های بصری در این حوزه مورد بررسی قرار می گیرند. توجه به این بخش اهمیت وافری برای مالکن وب سایت های بزرگ و پرمخاطب دارد. اغلب نرم افزارهایی که با عنوان پورتال (Portals) و دانش نامه (Wikis) منتشر می شوند در این زمینه غنی از امکانات هستند.

▪ هفتم؛ امکانات تعاملی (Interoperability) مورد نیاز تمام مجموعه هاست. این موارد بیشتر در نرم افزارهایی مطرح می شوند که با عنوان شبکه های اجتماعی (Social Network) منتشر می شوند. پشتیبانی از RSS و UTF-۸ و WebDAV و سازگاری با XHTML در این حوزه بررسی می شود. هر چه امکانات تعاملی وب سایت بالاتر باشد، امکان مشارکت مخاطبان در جریان محتوا افزایش خواهد یافت.

▪ هشتم؛ انعطاف (Flexibility) بیشتر مفهوم فنی دارد و به امکاناتی اشاره می کند که موجب دسترسی آسان تر به محتوا و مدیریت بهتر مجموعه می شوند. به عنوان مثال امکان بازنویسی آدرس اینترنتی برای هر صفحه (URL Rewriting) و امکان تعریف اطلاعات تکمیلی (Metadata) و امکان تولید محتوا و استفاده متعدد از یک محتوا (Content Reuse) یا پشتیبانی از امکان فنی CGI-Mode که برای برخی مجموعه های ضروری قلمداد می شود از این موارد است. چنانچه دو نرم افزار را که تفاوت های در این حوزه دارند با یکدیگر مقایسه کنید، خواهید دید که استفاده از نرم افزاری که شامل این امکانات است برای پشتیبان و مخاطب سهل تر خواهد بود.

▪ نهم؛ امکانات ذاتی (Built-in Applications) شامل تمامی امکانتی است که در سیستم های مختلف ذیل عناوین Module و Component شناخته می شوند و انجام فعالیت های اصلی مجموعه های تحت وب را در اختیار دارند. تمام آنچه که بلاگ، امکان چت، امکان دسته بندی، انواع گزارش گیری ها، تقویم، پرسش های مکرر، نظرسنجی، رای گیری، نظرات کاربران، نقشه وب سایت، امکان RSS و ویکی خطاب می شوند در این بخش قرار می گیرند. تنوع امکانات در این بخش به نوع نرم افزار بستگی دارد. به عنوان مثال نرم افزار e۱۰۷ در این باره فوق العاده فقیر است و برای پیاده سازی وب سایت های بزرگ مناسب نیست، حال آنکه نرم افزارهای Drupal و TikiWiki غنی از انواع امکانات هستند. ذکر این نکته ضرورت دارد که برخی امکانات به صورت ذاتی در بطن نرم افزار تعبیه نشده است. با مراجعه به وب سایت مرجع نرم افزار می توان از امکانات متعددی که در گذر زمان توسعه داده شده است استفاده کرد و دامنه فعالیت های نرم افزار را توسعه داد.

▪ دهم؛ تجارت الکترونیک (eCommerce) چند صباحی است مورد توجه اغلب توسعه دهندگان نرم افزارهای مدیریت محتوا قرار گرفته است و امکاناتی برای پشتیبانی از آن در بطن نرم فزارها قرار گرفته است. البته هستند نرم افزارهایی که به طور اختصاصی برای این کار طراحی و تولید شده اند. برخی از نرم افزارها امکانات ضعیفی در این حوزه عرضه کرده اند، اما بستر لازم برای توسعه این قبیل امکانات رادر بطن نرم افزار لحاظ شده است. برخی دیگر در این زمینه هم فقیر محسوب می شوند.

● نتیجه گیری

به طور قطع نمی توان گفت که فلان نرم افزار برای استفاده همگان مناسب است، اما تجربه های موفق بسیاری از شرکت ها خبر از موفقیت عام برخی نرم افزارها می دهد. از آنجا که استفاده از نرم افزارهای مبتنی بر زبان PHP را برای داخل کشور توصیه کردیم، می توانیم چند نرم افزار را برای کارهای مختلف معرفی کنیم. بدون شک Drupal بهترین گزینه برای وب سایت های پر ترافیک و بزرگ است که قابلیت مدیریت چندین زیر وب سایت را نیز مهیا کرده است. نرم افزارهای Joomla و mambo برای راه اندازی وب سایت های متوسط مناسب هستند. هرچند نرم افزار Movable Type با زبان Perl نوشته شده، اما همراه با WordPress بهترین گزینه برای دارندگان وبلاگ ها و وب سایت های جمع و جور محسوب می شوند. نرم افزار MediaWiki به عوان گزینه اول و TikiWiki به عنوان گزینه بعدی برای راه اندازی دانش نامه مناسب هستند. شرایط نرم افزارهای انجمن (Forum) مانند گذشته نیست و بسیاری از نرم افزارهای مدیریت محتوا امکانات مشابه و گاهی قوی تر عرضه می کنند. برای راه اندازی شبکه اجتماعی می توان از Drupal و Elgg استفاده کرد.

نرم افزارتجارت الکترونیک دوران ابتدایی رشد خود را طی می کنند و مانده است که بالغ شوند، اما OSCommerce برای استفاده گزینه مناسبی است. علاوه بر این حداقل بیست تا سی نرم افزار متن باز دیگر هم هستند که برای استفاده مناسب هستند. امیدواریم در آینده نزدیک مطالعه ای موردی ترتیب داده و نرم افزارهای معروف Plone و Drupal و Liferay را از جنبه های مختلف برای استفاده در سازمان های بزرگ مورد بررسی قرار دهیم.

نویسنده: جواد زارعی

ماهنامه تحلیلگران عصر اطلاعات

Introdução

Uma personal wiki é um sistema wiki mantido exclusivamente para uso pessoal na qual o próprio usuário é responsável por inserir as informações.

O seu objetivo é organizar e facilitar o acesso as informações da mesma forma como ocorre com wikis ‘comunitárias’.

Algumas pessoas mantêm suas wikis pessoais em servidores possibilitando o seu acesso em qualquer lugar. O uso de senhas para proteção do acesso a wiki é facultativo.

Este texto tem por objetivo listar os procedimentos necessários para  a implementação de uma personal wiki utilizando a engine mediawiki – que por sua vez é o mesmo motor utilizado pela wikipédia.

Para rodar a mediawiki é necessário ter instalado um web server que rode scripts perl e uma base de dados sql.

Neste tutorial faz-se uso dos seguintes aplicativos:

• Xampp (XAMPP Lite)
• Mediawiki
• Gimp

Instalação – Mediawiki

• Inicialmente instale o Xampp
• Inicie os módulos apache e o mysql
• Se preferir é possível configurar estes dois aplicativos para rodarem como serviço do windows

Para isso, abra o painel de controle do Xampp (XAMPP Control Panel), pare os módulos apache e mysql e ligue as opções Svc, conforme apresentado na figura abaixo:

• Caso tenha problemas após a instalação em rodar o apache, abra o arquivo xampplite\apache\conf\httpd.conf, procure pela linha  “Listen 80” e altere o valor 80 (porta padrão http) para o valor 8080 (esta porta é utilizada como porta alternativa para o protocolo http, contudo, outra porta poderá ser utilizada)
• Criação de database wikidb
  • Acesse o endereço http://localhost:8080/xampp/
  • No quadro da lateral esquerda da página aberta selecione a opção MyPHPAdmin dentro da seção Tools.
  • Neste mesmo quadro selecione a opção mySQL
  • No quadro principal, selecione a aba SQL, e insira as linhas abaixo e em seguida, clique em executar
    • create database wikidb;
    • grant create, select, insert, update, delete, alter, lock tables on wikidb.* to ‘root’@'localhost’ identified by ’senha’;
  • ‘root’ e ’senha’ representam respectivamente o usuário e a senha administrativa do servidor mysql.
  • Em \xampplite\phpMyAdmin, abra o arquivo config.inc.php e altere o usuário e a senha de acordo com os valores escolhidos
    • $cfg['Servers'][$i]['user']                 = ‘root’;
    • $cfg['Servers'][$i]['password']       = ’senha’;
  • Salve o arquivo

• Extraia o conteúdo do pacote referente a mediawiki para a pasta xampplite\htdocs e  renomeie o pacote extraído para, por exemplo, wiki.
• Acesse http://localhost:8080/wiki/  , onde  <wiki> representa o nome escolhido para o pasta que contém os arquivos da wiki.
• Clique na opção set up the wiki
• Preencha os seguintes campos
  

• Wiki name: Nome da wiki
  Language: pt-br – Português do Brasil
• Admin username: root
  (Confirm) Password: senha
• Database type: MySQL
  Database host: localhost
• Database name: wikidb
  DB username: root
  (Confirm) DB password: senha

• Finalize o processo de instalação
• Mova o arquivo /wiki/config/LocalSettings.php para o diretório pai.
• A wiki já está instalada e pode ser acessada a partir de http://localhost:8080/wiki/

Alterar o nome da página principal

• Para alterar  nome da página principal faça login com algum usuário com direitos administrativos (Para o exemplo: root)
• Abra a página principal e selecione a aba mover
• Insira o novo título em “Para novo título”
• Clique em “Mover página”

Criação e alteraração do logo da wiki

Pré-requisito: Gimp

• Crie uma nova imagem  através da opção Arquivo > Nova (sugere-se  largura=altura) 
• Para o exemplo utilizou-se 640×640
• Acesse o menu Filtros > Renderizar > Padrão > Quebra-cabeça
• Para o exemplo utilizou-se
  • Número de peças
  • Horizontal: 13
  • Vertical: 13
  • Largura do chanfro: 2
  • Reflexo: 0,5

• Na janela Camadas, crie uma nova camada:

• Botão direito sobre a janela de gerenciamento de camadas > nova camada
• Selecione a nova camada

• Adicione o logo ou texto desejado
• Ordene adequadamente as camadas (as camadas superiores são apresentadas no topo)
• Diminua a opacidade do quebra cabeça para exibir o logo

• Botão direito sobre a janela de camadas selecione copiar como é visto

• Selecione a camada recém criada (Visível) e selecione o filtro Filtros>Mapear>Mapear objeto
• Em opções gerais, selecionar a opção Mapear para: Esfera
• Habilitar fundo transparente

Saída obtida para o exemplo:

• Recorte e redimensione a figura para o tamanho 135×135 e coloque-a na pasta xampplite\htdocs\wiki\skins\common\images

• Abra o arquivo

• xampplite\htdocs\wiki\LocalSettings.php

• e substitua o logo padrão pelo novo logo através da inserção da linha

• $wgLogo = “$wgScriptPath/skins/common/images/triforce.png”;
  • onde triforce.png representa o nome do logo utilizado no exemplo.

SO / Pacotes  utilizados

• Sistema Operacional: Windows Vista Professional 64 bits
  
• gimp-2.6.7-i686-setup.exe
• mediawiki-1.15.1.tar
• xampplite-win32-1.7.2.exe

Referências:

http://en.wikipedia.org/wiki/Personal_wiki

Ce billet fait partie de la série “Personnalisons Wikipédia“.

La plupart des logiciels WYSIWYG permettent de modifier l’apparence d’un texte (mise en gras, italique, souligné, etc) à l’aide de raccourcis clavier (respectivement ctrl+b, ctrl+i, ctrl+u, …) La personnalisation d’aujourd’hui vous permettra de créer des raccourcis clavier en JavaScript afin d’avoir des facilités similaires lors de vos éditions sur Wikipédia

Introduction

(ceux qui ne s’intéressent pas aux explications peuvent passer directement au code complet, à la fin du billet)

Le code du jour fait appel à la notion d’évènement, pour lesquels vous trouverez plus d’informations sur Wikibooks. Les évènements qui nous intéressent ici sont ceux qui nous permettront de savoir quand l’utilisateur appuie sur une certaine combinaison de toucher sur le claviers, et sont au nombre de deux :

• “appui sur une touche du clavier” (onkeydown)

• “relachement d’une touche du clavier” (onkeyup).

Ces deux évènements permettent d’accéder en interne à un code correspondant à la touche qui viens d’être appuyée ou relachée.

—

Histoire de nous faciliter la vie, MediaWiki possède déjà une fonction JavaScript permettant de modifier un texte sélectionne comme l’on veux. Cette fonction est par exemple utilisée lorsque vous cliquez sur un des boutons au dessus (la barre de menu) ou en dessous (les listes de caractères spéciaux), en mode édition.

Cette fonction est insertTags(). Elle prend 3 paramètres, qui sont respectivement :

• les caractères à ajouter avant la sélection
• Les caractères  à ajouter après la sélection
• Le texte par défaut,  s’il n’y avait pas de texte séléctionné.

Exemple pour mettre un texte en souligné :

 insertTags('<u>', '</u>', 'souligné');

—

Note : Le code n’a été, pour l’instant, testé que sous Firefox 3.0 et 3.5.4. N’hésitez pas à me donner un feedback sur le bon fonctionnement (ou non) sur d’autres versions et navigateurs.

Note2 : il faut savoir que les raccourcis défini en javascripts seront prioritaires sur ceux du logiciel (du moins avec firefox)

Passons au code…

Conteneur

Histoire d’être un minimum propre, notre code sera, comme pour les autres de mes billets, encapsulé dans une fonction

function keyboardShortcuts() {
  // le code sera ici
}

Utilisation des évènements

La méthode pour définir une action (= l’appel à une fonction) sur les évènements qui nous intéresse est la suivante :

  document.onkeyup = function(e) { //l'user relâche une touche
    //code à executer
  }

  document.onkeydown = function(e){  //l'user appuie sur une touche
    //code à executer
  }

Problématique de la double touche

Problème : nous avons besoin de savoir lorsque l’utilisateur appuie à la fois sur “ctrl” et une lettre. Or, l’événement de base ne permet de le faire que pour une seule touche à la fois
Solution : créer une variable qui sait si ctrl est actuellement appuyé ou non

  var isCtrl = false; //la touche commence "non enfoncée"

  //l'evenement "onkeyup" est appelé à chaque fois qu'une touche est relachée.
  document.onkeyup=function(e) {
    if(e.which == 17) isCtrl=false;  //l'user relâche la touche ctrl (qui a le code 17). La variable passe a False
  }

  //l'evenement "onkeydown" est appelé à chaque fois qu'une touche est pressée.
  document.onkeydown=function(e){
    if(e.which == 17) { //l'user appuie sur la touche ctrl. La variable passe a True
      isCtrl=true;
    }
  }

Gestion des actions en elle-même

J’ai géré ci dessous 5 raccourcis :

• ctrl+b, pour mettre un texte en gras

• ctrl+i, pour mettre un texte en italique

• ctrl+l (L minuscule), pour faire un lien interne

• ctrl+m pour mettre le texte entre {{ }} et faire un modèle

• ctrl+u, pour souligner un texte

D’autres sont ajoutables à volonté, attention juste à ne pas utiliser des lettre dont vous vous servez souvent en édition pour vos raccourci (par exemple ctrl+x/c/V pour couper/copier/coller)

(sera mis dans la fonction d’onKeyDown)

    if( isCtrl == true ) {
       switch (e.which) { //quelle touche a été enfoncée ?
  	  case 66: //b
            insertTags("'''", "'''", 'gras');
            return false
	    break;
	  case 73: //i
            insertTags("''", "''", 'italique');
            return false
	    break;
          case 76: // l
            insertTags('[[', ']]', 'lien interne');
            return false
	    break;
          case 77: // m
            insertTags('{{', '}}', 'modèle');
            return false
	    break;
	  case 85: //u
            insertTags('<u>','</u>', 'souligné');
            return false
	    break
       }
     }

Résultat final

Pour les flemmards et ceux qui ont peur d’en oublier un morceau, le code complet ci dessous; recopiable tel quel :

function keyboardShortcuts() {

  var isCtrl = false;

  document.onkeyup=function(e) { //l'user relâche la touche ctrl. La variable passe a False
    if(e.which == 17) isCtrl=false;
  }

  document.onkeydown=function(e){
    if(e.which == 17) { //l'user appuie sur la touche ctrl. La variable passe a True
      isCtrl=true;
      return;
    }

    //gestion des ctrl+lettre que l'on veux ajouter.
    if( isCtrl == true ) {
       switch (e.which) { //quelle touche a été enfoncée ?
  	  case 66: //b
	    insertTags("'''", "'''", 'gras');
            return false
	    break;
	  case 73: //i
	    insertTags("''", "''", 'italique');
            return false
	    break;
          case 76: // l
	    insertTags('[[', ']]', 'lien interne');
            return false
	    break;
          case 77: // m
	    insertTags('{{', '}}', 'modèle');
            return false
	    break;
	  case 85: //u
	    insertTags('<u>', '</u>', 'souligné');
            return false
	    break
       }
     }
  }
  return true
}

//la fonction qui gère tous les appel de fonctions (du moins dans mes divers billets 
//!\ CELA VEUX DIRE QU'IL FAUT FUSIONNER AVEC LA FONCTION main() EXISTANTE, SI VOUS EN AVEZ UNE /!\
function main() {
  // [...  autres fonctions  ... ]

   if (wgAction == "edit" || wgAction == "submit")  { //à n'appeller que si en mode edition, sinon c'est inutile
      keyboardShortcuts()
   }
}

addOnloadHook(main)

Et Voili ! Comme d’habitude, n’oubliez pas de forcer le rafraichissement du monobook (ou vector) après avoir sauvegardé.

Source : Ce billet sur Lixya.org ; et un merci à Phe pour le coup de main

Edit : retiré un “]” qui trainait au milieu du code – forcement, ça marche mieux maintenant – désolé

“Wikimedia Commons” (ou plus simplement “Commons“)  est la banque de médias  centrale des projets Wikimedia, c’est à dire qu’elle stocke la plupart des images utilisées sur les différentes Wikipédias, Wikibooks, Wikispecies, etc.

Il y a actuellement environ 4000 nouvelles images importées sur Commons chaque jour, mais différents partenariats (voir par exemple, côté partenariats  celui ci et celui là) nécessitent des “batch“, des imports massifs de dizaines voire centaines de milliers d’images par bot dans un laps de temps relativement court.

Il y a une petite semaine, j’ai surpris une discussion intéressante entre un tecchie de la Wikimedia Foundation et un dresseur de bot sur le canal IRC  des développeurs, #wikimedia-tech .  J’y ai appris que l”espace disque des serveurs sur lesquels tournent Commons se fait rare. Pour fonctionner correctement, le système utilisé pour le stockage des images recommande fortement de ne pas remplir l’espace disque à plus de 80%. Nous avons dors et déjà dépassé cette limite (86%). D’après eux, à partir de 90% ça va commencer à sentir très mauvais  (voir ce qui est arrivé en juillet dernier).

De nouveaux serveurs ont dors et déjà été commandés, mais il n’arriveront que d’ici 3 à 5 semaines (plus 2/3 jours d’installation). C’est assez tard, mais 1) il y a des soucis de recrutements à la Wikimedia Foundation pour ces postes, ils sont en sous effectifs pour planifier les commandes et gérer le parc serveur en général 2) Sun (le fournisseur) est long pour la livraison de ce genre de commandes.

Pas de panique toutefois : les serveurs sont largement en mesure de supporter la charge normale (4000/jour) jusqu’à l’arrivée des renforts ; On ne peut par contre pas en dire autant si ça monte à 40.000/jour (typiquement, en cas d’import massif), donc les dresseurs de bots s’occupant des batchs ont été contactés pour leur demander d’appuyer  sur “pause” jusqu’à ce que la jauge d’espace libre repasse dans le vert.

Une fois le nouveau matos installé, Commons disposera d’un total de 24 Teraoctets de stockage

NB : par curiosité, j’avais demandé si supprimer les plus anciennes  “images effacées” (qui restent habituellement  physiquement sur les disques, pour permettre d’annuler la suppression ) des serveurs pour gagner de la place était une bonne idée, on m’a demandé en réponse si j’avais envie de déclencher une émeute chez les Wikipédiens

Ten ways of Web 2.0 strategies base on Mr Dion Hinchcliffe concept, I have made a web diagram for the following ways:

1^st: Back to the basics: Your Web site

In the rush to experiment with social media, community features, and sophisticated online services, it’s safe to say that some companies have lost focus. Build a rich, cleanly designed and useful Web site for your customers and they will come. As well, technical skills are still valuable despite the emphasis on “easier” Web development tools.

2^nd: Web development frameworks (browser, front-end)

Several popular tools: Adobe Flash, Adobe Air, Microsoft Silverlight, and to a certain extent, Java. These tools have reduced the gap between what your computer and your browser can do, make writing code much faster, Web-based, rich, line-of-business applications that we can use now taking lesser time to build compare in the past.

3^rd: Web development frameworks (browser, back-end)

“We are now seeing a clean break from what has come before to develop scalable, secure applications and services with Web 2.0 best practices,” Hinchcliffe says.

He cites Python and Ruby on Rails (both free) as two top programs. “We call these productivity-oriented frameworks because they can be 10 to 20 times more productive in developing code than older technologies,” he says. “That is enormous because when you are developing software, talent is most of the cost.”

4^th: Collaboration Software

Microsoft’s collaboration software, Sharepoint, which in its early days was a simple document sharing tool, is now chockfull of social networking features, including tools to support blogs, wikis, and a robust interactive community. It’s free version, Windows SharePoint Services, which comes with Windows, you can do BI, reporting, and integration, and it’s an entire application development platform as well.

Google Docs can easily do all the basics, including making bulleted lists, sorting by columns, adding tables, images, comments, formulas, changing fonts and more.

If you want to work and share docs within the team, now every team members can view and make changes at the same time. There’s an on-screen chat window for spreadsheets, and document revisions show you exactly who changed what, and when. We can also add in more details or comments.

Users love the tool because it consolidates information from many applications, and loves it because it’s a single technology they can use for many purposes.

5^th: SaaS

Software-as-a-service (SaaS) keeps growing and growing and growing, experts and analysts say, with many large companies adding SaaS components to on-premise software installations. Salesforce.com, considered the bellwether of the SaaS industry, reported record revenue of $305 million, up 23% from 2008, in its fiscal first quarter ended April 30, 2009. SaaS is winning favor because it’s often 20% cheaper than managing a non-premise application. SaaS is on track to be the dominant model for software by 2012. There are still lots of security issues, but the economics are definitely there. The other sweeping advantage is the flexibility that companies gain by rapidly adding new functionality. The paradigm shift is where you can go acquire a piece of what you need and assemble that into the software that you already own.

6^th: Cloud computing

It’s only a matter of time before cloud computing gains its place on center stage.

Sure, there are still security and reliability issues, but what aspect of IT doesn’t have that today?

Cloud services, offered by tech giants such as

• Google
• Amazon
• Microsoft
• Salesforce

They are making it relatively painless and certainly cheaper for a company to add infrastructure than if they were doing it themselves. They also gain best practices from the cloud provider. If the company decides it doesn’t need that extra infrastructure in six or 12 months, it simply cancels the service. That’s why enterprise customers are now doing cloud computing pilots, whereas a year ago, CIOs were turning up their noses at the concept.

7^th: Micro-blogging

Using social networking sites to broadcast news and other information about your company is a pretty darn cheap and widely acceptable way to engage with your community of partners, customers, and prospects. From the IT management side, there’s not much to do and why not educate your executives about the social Web?

“It’s virtually free, except for the labor involved, and you have unprecedented reach into decision makers,” says Jonathan Jaffe, founder of its-your-internet.com, a New York City-based company that advises organizations on technologies for online marketing.

This will change because as more people use Twitter these individuals will get bombarded, but now there’s a lot of accessibility. IT people are also broadcasting technical problems to the social Web and sometimes getting answers within an hour or two from vendors and experts.

8^th: Internal social networking

Companies are best off starting internally when experimenting with social media. For one thing, it’s better to make a mistake inside the company than with customers and influencers. For another, employees increasingly prefer to communicate via social media, and now, enterprise social networking tools incorporate security and other requirements that big companies seek.

Leading Web-based applications for internal blogs, micro-blogging, mashups, and wikis include Confluence by Atlassian, Socialtext, and the open-source MediaWiki. Such tools are often available at a fraction of the cost of traditional collaboration products (from companies such as Microsoft and IBM).

9^th: Bridging the gap between developers and finance

This isn’t a technology but a strategy; IT pros should stay close to the people who hold the purse when they are looking into new applications and projects, as always.

“From my point of view, having developed Web applications for the past 13 years, a key issue I’ve seen everywhere is the communication gap between the financial controller (FC) of the company and the development team members. So my advice is don’t focus too much on the buzzwords. Get in synch with your FC and look at your projects from a business point of view.” Dan Bridge, a UK-based developer

10^th: Thinking small

• The beauty of Web 2.0 is that you don’t have to invest loads of cash or time to experiment.

• Small projects are often the way to go. In fact, one might say that in today’s world of layoffs, small is big.

• Check out all the social media tools and sites that you can and then consider: Could any of these ideas work in-house or on our public site?

He aquí una guía de referencia rápida de Semantic Mediawiki y otras extensiones que funcionan sobre ella:

Sacado de http://postable.net/smwqr/

Introducción

Semantic Forms es una extensión que funciona sobre Semantic Mediawiki, cuyo propósito es facilitar la creación, edición y búsqueda de artículos con contenido semántico mediante formularios.

Los componentes principales de Semantic Forms son las páginas de definición de dichos formularios, existentes en el namespace Form:. Dichas páginas pueden ser editadas y creadas por cualquier usuario sin necesidad de saber programar. Puedes ser vistas como plantillas para forzar la creación de contenido semántico sin necesidad de usar el lenguaje propio de SMW.

Se pueden editar las páginas con los formularios creados añadiendo una pestaña “Editar con formulario”  (Edit with form).  Además Semantic Forms soporta auto-completar en la edición de los campos, de tal forma que los usuarios pueden elegir una opción sin fallos de ortografía o problemas de ambigüedad.

El texto que no tenga contenido semántico se puede incluir en un artículo gracias a una sección que se llama Texto libre (Free text).

Páginas especiales

Semantic Forms tiene varias páginas especiales asociadas:

• Special:CreateProperty – para crear propiedades.
• Special:CreateTemplate – para crear plantillas.
• Special:CreateForm – para crear formularios.
  NOTA: las propiedades, plantillas y formularios no se pueden editar una vez creados.
• Special:CreateCategory – para crear categorías.
• Special:CreateClass – para crear todo lo anterior de una vez (menos flexible, más rápido).
• Special:AddData – para añadir datos mediante los fomularios.
• Special:EditData – para editar artículos mediante los fomularios.
• Special:Forms – lista todos los formularios en la wiki.
• Special:Templates – lista todas las plantillas.
• Special:RunQuery – para realizar una búsqueda.
• Special:UploadWindow – para subir un fichero desde un formulario.

Definiendo formularios

Los formularios son creados mediante una serie de etiquetas (entre {{{…}}}) que especifican plantillas y campos dentro de esas plantillas. Las etiquetas permitidas son las siguientes:

• info – Información especial. Etiqueta opcional (al principio del formulario si se pone). Con parámetros:
  • partial form – indica que el formulario es parcial
  • add title=… – título para la página AddData que use este formulario
  • edit title=… – título para la página EditData que use este formulario
  • page name=… – fórmula para generar automáticamente el nombre del artículo que se crea; por ejemplo se pueden usar <NombrePlantilla[NombreCampo]> o <unique number;start=1>
  • only include free text – indica que el texto libre del formulario se mete en un <onlyinclude> en el artículo resultante para que no se transcluya la información semántica.
• for template … – Indica el comienzo de una inclusión de una plantilla (el fin es <end template>) y especifica el nombre de la misma (texto después de la etiqueta). Con parámetros:
  • label=… – especifica un texto para un cuadro que rodee todos los campos de esta plantilla
  • multiple – indica que el usuario puede realizar instancias múltiples de esta plantilla en el formulario. Al usar dicho formulario aparecería el trozo creado por esa plantilla con un botón debajo de “Añadir otro” o similar. Para poder almacenar el contenido semántico de estas plantillas instanciadas multiplemente, es recomendable usar la extensión Semantic Internal Objects.
  • chooser=… – similar a multiple; hace que la plantilla aparezca listada en un desplegable (…) dentro del formulario para añadir instancias, en lugar de aparecer con un botón Añadir. De esa forma sólo se puede escoger una
  • chooser caption=… – especifica el texto del desplegable
  • strict – especifica que sólo los campos del formulario que se correspondan con campos usados por la plantilla deban ser creados como elementos
• end template – fin de la plantilla
• field – Especifica un campo a incluir en el formulario, correspondiéndose con un campo de una plantilla. El texto después de la etiqueta es el nombre del campo en la plantilla. Con parámetros:
  • input type=text|textarea|date|datetime|datetime with timezone|radiobutton|checkbox|listbox|checkboxes – indica el tipo de entrada. Si el campo se corresponde con una propiedad semántica, el formulario tendrá el tipo correcto por defecto (si no, por defecto será text).
  • size=… – el ancho de un campo tipo texto o el alto en un campo tipo listbox
  • maxlength=… – máxima longitud de un campo tipo text o textarea
  • rows=… – filas de un textarea
  • cols=… – columnas de un textarea
  • mandatory – el usuario debe rellenar este campo
  • hidden – campo oculto en el formulario
  • restricted – campo editable sólo para admins/sysops
  • uploadable – especifica que al lado del campo debe ir un enlace que permita subir un fichero; aparecerá un popup donde elegiremos la imagen, y después de cerrarse aparecerá el nombre de la misma en el campo
  • upload filename=… – especifica el nombre del fichero que se pondrá a lo que se suba con el campo anterior. Se puede usar la variable <page name> para incluir el nombre de la página generada
  • autocomplete – activa el auto-completar para este campo, basado en los valores que tiene esta propiedad. No es necesario incluir este parámetro para el tipo Page (activado siempre)
  • no autocomplete – desactiva auto-completar para este campo
  • autocomplete on property=… – activa auto-completar usando los valores (páginas en caso de ser tipo Page o sin tipo) de la propiedad (…)
  • autocomplete on category=… – lo mismo con las páginas de la categoría (…)
  • autocomplete on concept=… – lo mismo con las páginas del concepto (…)
  • autocomplete on namespace=… – lo mismo con las páginas de un namespace (…)
  • autocomplete from url=… – igual pero cogiendo los valores de la URL (…)
  • remote autocompletion – indica que los valores deben ser consultados del servidor mediante AJAX en lugar de coger los valores de la página.
  • property=… – indica la propiedad semántica a la que corresponde este campo; coge automáticamente el tipo y los valores del autocomplete
  • default=… – valor que trae el campo por defecto. Si ponemos “now” en los tipo date, se rellena con la fecha; si ponemos “current user” se rellena con el nombre del usuario
  • values=… – especifica una serie de posibles valores que puede tener el campo, mostrados en un desplegable. Sobreescribe los valores de una propiedad
  • values from category=… – lo mismo que values pero coge como valores los nombres de las páginas de la categoría (…)
  • values from concept=… – lo mismo que el anterior pero para el concepto (…)
  • list – especifica que este campo contiene una serie de valores para autocomplete
  • delimiter=… – especifica el delimitador (caracter o string) si este campo admite una lista de valores. Por defecto es “,”
  • class=… – especifica una clase CSS que la entrada de este campo debe tener
• choosers – Especifica el campo para seleccionar las plantillas marcadas con chooser. Aparece como mucho una vez en la declaración del formulario.
• standard input … – Especifica un tipo especial de campos, de entre 8 distintos; como son los botones de Previsualizar y de Guardar. El más importante es “free text” (este texto va después de la etiqueta standard input| ) para contener texto sin contenido semántico. Sus parámetros son los siguientes:
  • rows=…
  • cols=…
  • hidden
  • restricted
  • default=…
  • preload=… – especifica una página cuyos contenidos deben ser precargados en este campo
  • label=… – especifica el texto asociado con este campo

Cada tipo de dato en SMW tiene un campo por defecto, y en algunos casos también un tamaño. La tabla con estas relaciones se puede consultar aquí.

Para el tipo de campo free text, podemos usar un editor WYSIWYG. Si tenemos instalada la extensión FCKeditor, nos aparecerá dicho editor en este campo (y solo en este).

Campos con múltiples valores

Es posible definir campos semánticos para que admitan varios valores, separados por comas u otro delimitador. Para conseguir esto, la plantilla debe contener la función #arraymap. La llamada genérica a esta función tiene la forma:

{{#arraymap:valor|delimitador|var|formula|nuevo_delimitador}}

La función corta el valor por el delimitador, y para cada trozo, aplica la misma regla que aplica formula a var; y para terminar une los resultados usando el nuevo delimitador. Esto resulta muy útil; por ejemplo, si tenemos un formulario para poblar el campo sinonimo, y queremos coger los valores introducidos y meterlos en la página como propiedades, podemos hacer lo siguiente:

{{#arraymap:{{{sinonimo|}}}|,|xxx|[[Has synonim::xxx]]}}

Si usamos la página especial CreateTemplate para crear la plantilla, existe una opción para introducir automáticamente esta función parseadora para cada campo que pueda tomar más de un valor. Por cierto, el string \n se convertirá en un salto de línea.

Campos para Categorías

Es posible tener unos campos especiales para categorías usando la extensión CategoryTree. Se puede encontrar más información sobre este tipo de campos aquí.

Definiendo el final del formulario

Gracias a la etiqueta standard input, podemos modificar los botones que aparecen al final del formulario para editar una página. Los 7 valores permitidos (aparte de free text) son:

• save – para el botón de Grabar la página
• preview – para el botón Previsualizar
• changes – para el botón de Mostrar Cambios
• summary – para el texto del campo Resumen
• minor edit – para el checkbox de edición menor
• watch – para el checkbox de Seguir esta página
• cancel – para el enlace Cancelar

Para modificar por ejemplo el botón de Grabar podemos escribir la siguiente etiqueta en la definición del formulario, con el texto a introducir en el botón:

{{{standard input|save|label=Guardar los cambios}}}

Si no incluímos ninguna etiqueta de estas, los botones y textos aparecerán como en la edición de cualquier artículo. Pero en cuanto incluyamos una sola, aparecerán sólo los standard inputs que hayamos declarado, y en el mismo orden.

Formulario de ejemplo

Podemos ver a continuación el código de la definición que genera este formulario:

{{{info|add title=Add an opinion item|edit title=Edit an opinion item}}}
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Item}}}
{|
! Author:
| {{{field|author|mandatory}}}
|-
! Source:
| {{{field|source|mandatory}}}
|-
! Date:
| {{{field|date}}}
|-
! URL:
| {{{field|url}}}
|-
! Quote:
| {{{field|quote|input type=textarea}}}
|}
{{{end template}}}

{{{for template|Opinion|label=Opinions for this item|multiple}}}
'''Topic:''' {{{field|1}}}

'''Position:''' {{{field|2|size=55}}}

'''Stance:''' {{{field|3|size=10}}}
{{{end template}}}

{{{for template|Reference|label=Previous opinion items this item refers to|multiple}}}
'''Item name:''' {{{field|1|autocomplete on category=Items}}}
{{{end template}}}

'''Free text:'''

{{{standard input|free text}}}

{{{standard input|summary}}}

{{{standard input|minor edit}}} {{{standard input|watch}}}

{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}

Notar la presencia de wikitexto y algo de HTML. Este código se generó usando la página CreateForm y 3 plantillas distintas. La etiqueta wikiPreview se incluye para que la previsualización se haga en la misma página.

Añadir y editar datos

El proceso de añadir datos está normalmente estructurado en 2 pasos; primero el usuario introduce el nombre de un artículo, y segundo es enviado a un formulario para crear o editar dicho artículo, dependiendo de si ya existía o no, asegurando que no se sobreescriba una página. Existen 2 maneras de añadir datos siguiendo este modelo:

1. Usando la función parseadora “forminput”, de tal forma que al añadir dicha etiqueta a cualquier página se cree un campo donde irá el título de la página a añadir/editar. Por defecto esta etiqueta se incluye en cada formulario creado mediante CreateForm. La llamada genérica a esta función es:

       {{#forminput:nombre_formulario|tamaño|valor|texto_boton|query_string}}

   Todos los parámetros son opcionales:

   • nombre_formulario – nombre del formulario de Semantic Forms a usar. Si se deja en blanco, aparecerá un desplegable con todos los disponibles
   • tamaño – tamaño del campo texto
   • valor – valor por defecto del campo
   • texto_boton – texto en el botón Enviar
   • query_string – serie de valores que se quieren pasar al formulario; ejemplo: “namespace=es&Palabra[Tipo]=verbo”. Podemos hacer que la nueva página sea subpágina de la actual poniendo “super_page={{PAGENAME}}”.
2. Usando la página especial AddPage. Si visitamos Special:AddPage, veremos un campo para poner el nombre de la nueva página y un desplegable para seleccionar el tipo de formulario. También podemos visitar Special:AddPage/nombre_formulario para especificar el tipo. Si queremos especificar el namespace, podemos visitar Special:AddPage/nombre_formulario/Namespace:nombre_namespace.  Si queremos crear una subpágina basta con poner / en el nombre.
   

Podemos seguir otro modelo que realizará el proceso en 1 paso. Se basa en que el nombre de la página se crea automáticamente añadiendo el parámetro page name dentro de la etiqueta info (definición del formulario). Como se explicó con anterioridad, existen dos tipos de variables que se pueden usar en dicho campo:

• <NombrePlantilla[NombreCampo]> – reemplazado por el contenido de es campo
• <unique number;start=numero> – reemplazado por un número que hace el nombre de la página único

Para usar este modelo, los usuarios deben ser llevados a Special:AddData/nombre_formulario. Si no indicamos el nombre, iremos a la página donde tendremos que indicarlo, y eso sobreescribirá lo que pongamos en form name. Podemos crear esa URL usando la función #formlink en vez de hacerlo directamente, de la siguiente forma:

{{#formlink:nombre_formulario|texto_enlace|tipo_enlace|query_string}}

donde el primer, el segundo y el cuarto parámetro van como en #forminput; y tipo_enlace puede ser “button”, o “post button” para enviar los datos por POST (más robusto con caracteres especiales o muchos parámetros). Ejemplo:

{{#formlink:<Form Name>|Push This Button|button|title=Semantic Forms&action=formedit#tab=Summary}}

Precargar datos en un formulario

Puede ser interesante que un formulario para crear una página contenga ya algunos campos prefijados a valores determinados. Existen varias maneras de lograr esto:

• especificando el valor “default” para el campo en cuestión
• especificando el parámetro preload en standard input|free text para rellenar el campo de texto libre con el contenido de una página
• añadiendo “preload=nombre_pagina” al campo query_string en la llamada a forminput rellenaremos los campos con los de la página en cuestión
• de forma similar podemos hacer lo mismo en el query_string de la URL para AddPage o AddData.
• añadiendo “nombre_plantilla[nombre_campo]=valor” al query_string en la llamada a forminput rellenaremos el campo con el valor especificado. Podemos repetirlo usando &.
• de forma similar podemos hacer lo mismo para AddPage y AddData.
• podemos crear nuestro propio manejador, usando el hook “sfEditFormPreloadText”. Si otra extensión llama a este hook, puede precargar los datos que quiera. Para poder hacer esto debe tener una cabecera como “function-name(&$page_contents, $page_title, $form_title)”.

La pestaña “Editar con formulario”

Hay 3 formas de hacer que aparezca la pestaña en páginas específicas:

1. La forma recomendada, usando categorías. Las categorías son la forma estándar de definir el tipo de una página en Semantic Mediawiki. La forma más fácil de meter una página en una categoría es introduciendo una etiqueta category en la plantilla principal de ese tipo de página. Una vez hecho esto, se debe meter la propiedad “Has default form” en la página de la categoría. Se puede hacer automáticamente si se crea la categoría mediante Special:CreateCategory. Se puede ver un ejemplo aquí y aquí.
2. Usando namespaces. Poniendo la propiedad “Has default form” en la página del namespace (posiblemene nombre_wiki:nombre_namespace) haremos que cada página en el namespace tenga la pestaña.
3. Usando páginas específicas, poniendo la propiedad “Page has default form” en la propia página.

Puede interesar renombrar o quitar la otra pestaña “Editar”; para ello existen unos flags a modificar en LocalSettings.php o en SF_Settings.php:

• $sfgRenameEditTabs – renombra la pestaña “Editar con formulario” a “Editar”, y la pestaña “Editar” a “Editar código fuente”
• $sfgRenameMainEditTab – renombra sólo la pestaña “Editar” a “Editar código fuente”
• $wgGroupPermissions[...]['viewedittab'] – puede ser establecida para distintos tipos de usuarios, de forma que sólo algunos verán el antiguo “Editar” Una modificación corriente es ponerlo a false para usuarios tipo ‘*’, y a true para usuarios ’sysop’.

Enlaces rojos

Por defecto, los enlaces rojos en Mediawiki (los que apuntan a una página que no existe) nos llevan a la página para añadir un artículo usando el formulario estándar. Sin embargo, si el enlace rojo es el valor para una propiedad semántica, puede apuntar al formulario adecuado para añadir ese tipo de página. Necesitamos:

1. añadir la propiedad “Has default form” a la página de dicha propiedad. Esto se puede hacer directamente creando la propiedad mediante Special:CreateProperty
2. podemos añadir también uno o más “Has alternate form” a la página de la propiedad para dar al usuario a elegir cuando pinche en el enlace rojo.

Notar que si hemos definido “Has default form” para el namespace, al pinchar en un enlace rojo que va a una página de ese namespace, nos llevará al formulario AddData correcto.

Realizar búsquedas

Para ello existe la página especial Special:RunQuery, que nos mostrará un formulario como el de AddData o EditData.

Otras características

• Convertir formularios largos en formularios multipestaña usando la extensión Header Tabs.
• Formularios parciales para poder editar las secciones de una página por separado.
• Posiblidad de tener la librería YUI (Yahoo UI Javascript) en local en lugar de acceder a yahoo.
• Capacidad para definir nuevos campos usando hooks. Leer más aquí.
• Posibilidad de usar Semantic Forms para la revisión de páginas (historia) usando la extensión SemanticHistory.

Usando Semantic Forms en tu wiki

Pasos a seguir para el uso de Semantic Forms ( sacado de http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Example ):

1. Definir estructura: tipos de páginas y datos que contiene cada una
2. Crear propiedades (Special:CreateProperty)
3. Crear plantillas (Special:CreateTemplate) – una o varias por tipo de página; son las que van a albergar la estructura
4. Crear formularios (Special:CreateForm) – uno por tipo de página; para rellenar la(s) plantilla(s) que pertenezca(n) a cada tipo
5. Crear categorías (Special:CreateCategory) – cada categoría se asocia a un formulario, de forma que los artículos creados con dicho formulario se metan automáticamente en la categoría.
6. Enlazar formularios – para que los usuarios puedan acceder a ellos.
7. Añadir datos (Special:AddData) – para probar que lo anterior funciona.

Fuente: http://www.mediawiki.org/wiki/Extension:Semantic_Forms

Problemas comunes: http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Common_problems

Wiki ejemplo: http://www.wikimanga.net/wiki/Wikimanga:Iniciar_artículo

Propiedades

En SMW existen las llamadas anotaciones semánticas que tienen un lenguaje especial. Aparte de esto, la edición es igual que en mediawiki.

Las anotaciones semánticas pueden ser vistas como una extensión al sistema de categorías existente en mediawiki. SMW nos permite realizar una anotación en cualquier texto o link para describir su contenido; de tal forma que se convierten en propiedades del artículo. Esto permite a los usuarios ir más allá de las categorías, y también que el contenido sea accesible por máquinas.

La sintaxis de una propiedad es la siguiente:

[[propiedad::valor]]

El artículo donde se incluya mostrará sólo el valor. Por ejemplo, para escribir un enlace a “Claro” en el Artículo “Oscuro” pondríamos en mediawiki [[Oscuro|Oscuro]], pero en SMW para indicar que se trata de un antónimo, escribiríamos [[antonimo::Oscuro]]. Para mostrar un texto alternativo al valor de la propiedad, podemos escribir [[propiedad::valor|texto]]

Cada propiedad tiene su artículo en mediawiki, empezando por “Property:”. Se pueden ver todos en Special:Properties.

Además de esto, hay que tener en cuenta que ésto se mostrará en el artículo como un hipervínculo, a no ser que la propiedad sea de un tipo específico, en cuyo caso se mostrará como texto normal (preferible en muchas ocasiones, como por ejemplo para una propiedad numérica). Existen varios tipos predeterminados en SMW, como por ejemplo number, que se pueden usar gracias a la propiedad “has type”. Lo que tenemos que hacer para declarar una propiedad de un tipo es ir a su página (Property:…) y escribir por ejemplo [[has type::number]]. El tipo por defecto es Type:Page, por lo que se crea un enlace.

Otra forma de poner las propiedades en un artículo es mediante #set. De esa manera no aparecerá ni como enlace ni como texto. Para propiedades que abarcan varias fechas se puede usar #set_recurring_event.

Tipos de propiedades y unidades

Podemos consultar los tipos de datos disponibles en Special:Types. A continuación la lista:

• Type:Page – enlaza páginas (por defecto)
• Type:String – texto
• Type:Number – números enteros y decimales con exponente opcional. Permite poner unidades después del número, y las reconocerá si están definidas como unidades.
• Type:Boolean – true/false, yes/no, 1/0
• Type:Date – fecha
• Type:Geographic coordinate – coordenadas
• Type:Text – como String pero sin límite de longitud. Pero no puede ser usado para búsquedas
• Type:Code – como Text pero muestra el valor como texto preformateado en un recuadro
• Type:Temperature – temperatura
• Type:URL – enlace externo
• Type:Annotation URI – relaciones con objetos externos
• Type:Email – link a dirección de email, con mailto.

En cualquier propiedad se puede limitar el rango de valores a tomar, usando la propiedad Property:Allows value para enumerar los valores permitidos.

Una propiedad podría tener varias más ligadas. Hay dos formas de implementar esto:

1. Crear una página para la propiedad principal (la que podríamos tratar como un objeto) que sería de tipo Type:Page, e incluir el resto de propiedades en dicha página.
2. Usar una característica de SMW: una propiedad puede tener múltiples tipos, por lo que se puede definir por ejemplo como Type:Page,Type:Date,Type:Date sin problema.

Para que una propiedad pueda estar expresada en varias unidades, debemos definir la relación entre ellas, de tal forma que se pueda realizar la conversión. Existen dos casos:

1. Cuando las unidades son directamente  proporcionales (una se obtiene multiplicando la otra por un factor fijo) debemos escribir en la página de la medida (por ejemplo Type:Potencia) lo siguiente:
   [[Corresponds to::1 W, Watios, Watts]] #unidad principal
   [[Corresponds to::0.001 KW, Kilowatios]] …
   (recordar que para usar dicha unidad de medida se usará [[Has type::Potencia]])
2. Cuando las unidades no son directamente proporcionales se pueden hacer un par de cosas que escapan al objetivo de este mini tutorial.

Plantillas semánticas

Las plantillas semánticas son una forma de incluir el lenguaje empleado por SMW sin tener que escribirlo cada vez. Esto tiene varias ventajas: los usuarios no tienen que aprender nuevo lenguaje y las anotaciones se usan de forma consistente.

Por ejemplo podemos crear una plantilla para mostrar gerundio y participio en la página de un verbo, y usarla así: {{formas|gerundio|participio}}. En la página de la plantilla tendríamos que incluir [[Gerundio::{{{1}}}]] y [[Participio:{{{2}}}]] en la parte donde quisiéramos que se mostrase, por ejemplo una tabla. Como era de esperar, el meter la propiedad en la plantilla no hace que esa propiedad sea de la propia plantilla. Para evitar que se muestren en blanco o muestren error campos que no están rellenos, se pueden usar condicionales en la plantilla para que se muestre por ejemplo la fila de una tabla sólo si la propiedad tiene valor asignado (para estas cosas es muy útil la extensión ParserFunctions).

Podemos usar Semantic Forms para editar el contenido de las plantillas.

Enlaces a servicios online

Podemos hacer que una propiedad enlace a un servicio online, como por ejemplo puede ser Google Maps. Para ello tendremos que escribir lo siguiente en la página de la propiedad: [[provides service::online maps]]; siendo online maps un set de enlaces proporcionados por la wiki. Después de realizar esto, aparecerá un signo de interrogación al lado de la propiedad que al pulsarlo nos mostrará los distintos servicios disponibles. Para este ejemplo, siguiendo un criterio de SMW, los enlaces se pondrían en la página Mediawiki:Smw service online maps, siguiendo la siguiente estructura. La creación de dichas páginas sólo debería estar disponible para administradores y usuariso especiales.

Como se puede apreciar en el enlace anterior, cada línea de la página tiene la forma texto | enlace. El texto es lo que se mostrará al pulsar en el icono correspondiente, y el enlace es donde se nos llevará al hacer clic. Como es natural, tendremos que incluir parámetros a esa URL si queremos ir a una página concreta dentro de la web apuntada; estos parámetros son instanciados como $1, $2, $3,… pudiendo crear cualquier URL por compleja que sea. Dependiendo del tipo de dato que tenga la propiedad, los parámetros son unos u otros (normalmente el más importante es $1, dando el valor de la propiedad “URL safe”):

Type:Page
$1: nombre del artículo válido en URL; sin espacios y con guiones bajos
Type:Number (y tipos con unidades)
$1: valor numérico con puntuación inglesa
$2: valor entero con puntuación inglesa
$3: unidades, si existen
Type:String (no Type:Text)
$1: string, válido en URL
Type:URL, Type:Annotation URI y Type:Email
$1: valor de la URL, URL-encoded (incluye mailto: para Type:Email)
Type:Geographic coordinate
$1: latitud (grados)
$2: longitud (grados)
$3: latitud (minutos)
$4: longitud (minutos)
$5: latitud (segundos)
$6: longitud (segundos)
$7: latitud (dirección: N o S)
$8: longitud (dirección: N o S)
$9: latitud (grados decimales)
$10: longitud (grados decimales)
$11: signo (- si S) para latitud
$12: signo (- si W) para longitud

Exportar datos

Para completar las propiedades de SMW, tenemos varias características que permitirán que las máquinas puedan leer y procesar el contenido semántico de nuestra wiki.

Los usuarios pueden exportar los datos de un artículo desde Special:ExportRDF o escribiendo directamente como URL: <url_wiki>/Especial:ExportRDF/<nombre_artículo>. (podemos pasarle parámetros por GET; como por ejemplo backlinks=1 o recursive=1 para decirle que artículos a partir del original queremos que enlace, o xmlmime=rdf). Esto generará documentos legibles para máquinas, en formato OWL/RDF. También existe un script que exporta todo el contenido semántico: SMW_dumpRDF.php (carpeta maintenance, puede ser ejecutado en un cron periódicamente). Se puede importar un vocabulario externo (p.ej. FOAF) y asociar atributos y relaciones en SMW con dicho lenguaje. Por añadir algo más, la inclusión de un artículo en una categoría se exporta como rdf:type, y la inclusión de una categoría en otra como rdf:subClassOf.

Existen numerosas herramientas que pueden usarse con SMW y la exportación de RDF:

• Geocoding Tools for Python – devuelve las coordenadas de un edificio simplemente dándole el nombre del mismo. Se encarga de buscar en varias wikis semánticas.
• Tabulator, Longwell, FOAF Explorer – navegadores RDF
• Piggy Bank – extensión para Firefox

Importar

En SMW es posible importar y reusar vocabulario que pertenece a otras wikis o a un estándar predefinido, asociando elementos del vocabulario con términos de la wiki. Por ejemplo, para importar foaf:knows (previamente habilitado por el administrador), habrá que escribir en un artículo [[imported from::foaf:knows]] (en imported from veremos los formatos disponibles y las correspondencias entre nombre – URL). Importar así una propiedad supone definir automáticamente el tipo, por lo que habría que borrar la propiedad has type en caso de existir. Se pueden importar vocabularios y ontologías, usando varios métodos que no voy a explicar aquí, ya que en el manual de SMW vienen extensamente explicados para el que lo necesite.

Ülesanne: Oletagem, et ühel päeval heliseb telefon ja toru otsas on Wikipedia looja Jimbo Wales küsimusega: “Kuidas võiks Wikipediat veelgi paremaks teha?” Mida talle vastata?

Mediawiki

• No minu esimene probleem oleks kohe WYSIWYG editori puudumine vaikimisi. Inimesed saavad küll artikleid kirjutada, kuid peavad selleks kasutama wiki notatsiooni, mis on küll lihtsam kui HTML, kuid ikkagi vahepealne lahendus teel tõelise WYSIWYG poole. (Kogukonna poolt pakutavatest lisadest parim on FCKeditor.)

• Samuti saaks piltide ja muu meedia lisamist kindlasti lihtsustada kasutades AJAXit.

Kuid need on kõik tarkvaralised probleemid, millega olen ise kokku puutunud Mediawikit näppides ja nendega tegeletakse. Tegu rohkem “nice to have” asjadega, mitte kriitiliste probleemidega.

Wikipedia

Wikipedia peaprobleemiks on sisu kvaliteet, kuna artikleid loovad tavalised inimesed ehk nö mitte-autoriteetsed allikad. Üks Wikipedia loojatest ja de facto juht Jimmy Wales aga vaidleb selles osas vastu, et suvalist entsüklopeediat ei peaks kasutama peamise infoallikana.

Siinkirjutaja arvates võib kvaliteedi üle virisemine ju õige olla, kuid teisalt võttes ei ole lihtne ette kujutada alternatiivset meetodit sellise eksponentsiaalse infohulga töötlemiseks. Pealegi suur osa infost muutub ja täieneb iga päev ning vaevalt tuleb Entsüklopeedia Kirjastus teile koju Eesti Entsüklopeediasse täiendusi ja muudatusi juurde kirjutama. Klassikalised autoriteetide poolt koostatud entsüklopeediad käsitlevad vaid murdosa kogu teabest ja selles nad ongi head.

Samas saab selle vähemuutuva teabe kindlasti tänapäeval ka Wikipediast lihtsalt kätte. Ja kuna paber maksab, siis paber-entsüklopeediast ka tunduvalt põhjalikumalt. Kui just keegi pole näiteks primaatide peale pahaseks saanud, et nende artiklit ära solkida.

Wikipedia mudel

.. on lihtne – kõik saavad artiklit muuta. Süsteem põhineb oletusel, et palju heatahtlikke infomuutjaid likvideerib ära kuritahtlike vandaalide poolt tekitatud kahju. Seega soga võib lisanduda, kuid ajapikku kvaliteet kumuleerub.

Lühidalt: tõenäoliselt pole ma ainus arvates, et Wikipedia väärtus kaalub kaugelt üle tema mõned pisipuudused.

After introducing the XML format of Entity Framework’s edmx files, let’s use that knowledge to create a small XSLT style sheet which displays the mappings of tables and entities in a Wiki-style table (which can be used in MediaWiki and SharePoint wikis).

In the XSLT root, we need to declare all namespaces used by the edmx to access nodes and attributes:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx"
    xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/
				EntityStoreSchemaGenerator"
    xmlns:ssdl="http://schemas.microsoft.com/ado/2006/04/edm/ssdl"
    xmlns:cs="urn:schemas-microsoft-com:windows:storage:mapping:CS"
    xmlns:edm="http://schemas.microsoft.com/ado/2006/04/edm"
    xmlns:a="http://schemas.microsoft.com/ado/2006/04/codegeneration"
    xml:space="default" >
<xsl:output method="html" omit-xml-declaration="yes"  />

<!-- input file is C:\path\to\Model.edmx -->

This XSLT does not start with the mappings section, but with the tables and views inside the Schema definition, and then looks up their Mappings definition:

<xsl:template match="/">
  <xsl:apply-templates
    select="edmx:Edmx/edmx:Runtime/edmx:StorageModels/ssdl:Schema" />
</xsl:template>
<xsl:template match="ssdl:Schema">
<html>
  <body>
    <table width="100%">
      <xsl:apply-templates select="ssdl:EntityType" >
        <xsl:with-param name="namespace" select="@Namespace" />
      </xsl:apply-templates>
    </table>
  </body>
</html>
</xsl:template>

This code creates a table row for each database table and its class:

<xsl:template match="ssdl:EntityType" >
  <xsl:param name="namespace"></xsl:param>
      <xsl:variable name="table" select="@Name" ></xsl:variable>
      <xsl:variable name="map"
        select="/edmx:Edmx/edmx:Runtime/edmx:Mappings/cs:Mapping/
          cs:EntityContainerMapping/
          cs:EntitySetMapping[cs:EntityTypeMapping/
                            cs:MappingFragment/@StoreEntitySet=$table]" />
      <xsl:variable name="s" select="$map/*/@TypeName" />
      <xsl:variable name="p"
          select="concat('IsTypeOf(',
            substring($namespace, 1, string-length($namespace) - 5))" />
      <xsl:variable name="class"
          select="substring($s, string-length($p) + 1,
            string-length($s) - string-length($p) - 1)">
      </xsl:variable>
  <tr valign="top">
    <td >
      [[<xsl:value-of select="@Name"/>]]
    </td>
    <td>
      <xsl:value-of select="$class" />
    </td>
  </tr>
</xsl:template>
</xsl:stylesheet>

The [[ ]] notation creates a wiki hyperlink that allows developers to document tables and entities, and link to other documentation.

No son gran cosa, no estan muy desarrolladas, y no son complejas.

He montado una Mediawiki en el Equipo de mi casa (ahora ya en Internet), y una pequeña Web en HTML en mi DropBox, para compartir todos los archivos.

Así que si necesitais protección Antivirus, o algun tipo de software para WinXp, entrar en
Mi Dropbox

Por otro lado, mi MediaWiki esta abierta a participación, no dudeis en escribir lo que sea. No hay censura (pero si Anti-Spam xd)

Xavi Gonzalez Wiki

Un saludo!

Depois de algumas semanas de pequisas, para desenvolver uma página que crie uma conta em um servidor Wiki (software Mediawiki), consegui a seguinte solução.

Arquivo frmcreateUser.php
Página formulário

<html>
<body>
<form action="createUser.php" method="POST">
<h2>Formulario para a criacao de usuarios "wiki.claretiano.edu.br"</h2><br/><br /><br />
Login: <input type="text" name="login" /><br /><br />
Senha: <input type="text" name="senha" /><br /><br />
E-mail: <input type="text" name="email" /><br /><br />
Nome Real: <input type="text" name="nome" /><br /><br />
Grupo: <input type="text" name="grupo" /></br /><br />
<input type="submit">
</form>

<body>
<html>

Arquivo createUser.php
Cria o usuário e adiciona em um grupo

<?php

/**
* Criar conta e promover usuario
*
*@autor Alexandre Silva (alexandre260678@hotmail.com)
*/

$path="/var/www/wiki/wiki";
putenv("MW_INSTALL_PATH={$path}");
require_once ("{$path}/includes/WebStart.php");

$user=User::newFromName($_POST["login"]);

# Testa se o usuario esta em branco
if (! is_object($user)) {
echo ("Usuario invalido.\n");
die();
}

$user->addToDatabase();
$user->setPassword( $_POST["senha"] );
$user->setEmail( $_POST["email"] );
$user->setRealName( $_POST["nome"] );
$user->confirmEmail();

# Promove para um grupo
$user->addGroup($_POST["grupo"]);

$user->saveSettings();
$ssUpdate = new SiteStatsUpdate( 0, 0, 0, 0, 1 );
$ssUpdate->doUpdate();

?>