InflateColumn::Markup::Unified inflates columns that use a markup language

[Ido Perelmutter-2]

Hi everyone.

Two modules I've created: Markup::Unified and DBIx::Class::InflateColumn::Markup::Unified are now on CPAN. The first one was written just to facilitate the second one. What I wanted here was a way to automatically process text columns that use one of the three popular markup languages Textile, Markdown and BBCode.

So, if you have, for example, a database with a comments table, where comment text is written in Textile syntax, then DBIx::Class will automatically process the text into HTML. Not only that, you don't even have to enforce just one markup language on a column, and allow all three. This is useful, for example, if you want to allow the users who comment to do so with their preferred markup language.

Anyway, I'd really like to get any ideas, suggestions and complaints you may have. If you want support for another markup language, I'll be glad to add it.

Thanks,
Ido Perlmuter.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Bernhard Graf-4]

Ido Perelmutter schrieb:

> Two modules I've created: Markup::Unified and
> DBIx::Class::InflateColumn::Markup::Unified are now on CPAN. The first
> one was written just to facilitate the second one. What I wanted here
> was a way to automatically process text columns that use one of the
> three popular markup languages Textile, Markdown and BBCode.
>
> So, if you have, for example, a database with a comments table, where
> comment text is written in Textile syntax, then DBIx::Class will
> automatically process the text into HTML. Not only that, you don't even
> have to enforce just one markup language on a column, and allow all
> three. This is useful, for example, if you want to allow the users who
> comment to do so with their preferred markup language.
>
> Anyway, I'd really like to get any ideas, suggestions and complaints you
> may have. If you want support for another markup language, I'll be glad
> to add it.

OK, here is mine:

Even though I appreciate every effort for DBIC, I wouldn't use your
module, because it breaks the widely adopted MVC paradigm by doing the
formatting in the model. What if I wanted my output in PDF, for example?

To play nicely with MVC systems, your module should transform any of the
supported markup codes into some common abstract object instance.
The task of formatting that object belongs to the view.

Since none of the existing (e.g. Catalyst) View classes yet support such
an abstract markup object (and I bet none ever will), you - or anyone -
could write formatters for popular formats, e.g.
Markup::Unified::Formatter::HTML, Markup::Unified::Formatter::PDF etc.

That's very much the way how DateTime works, btw.

Bernhard

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Jose Luis Martinez]

Hi,

Nice module!

> Anyway, I'd really like to get any ideas, suggestions and complaints you
> may have. If you want support for another markup language, I'll be glad
> to add it.

My two suggestions:

1 - I would make the "column to get the markup language from"
configurable. It seems like it can only be called 'markup_lang'.

2- I see that the Markup::Unified module requires, uses, and makes an
instance of the three markup modules that are supported. IMHO, I don't
think this is a good long-term strategy if you are willing to support
more modules because:
  - If you only want to use one markup_lang, you have to install all, or
the module fails to load.
  - People have to "bug" you, as the maintainer of the module to get
their markup language supported by Markup::Unified.
  - All markup modules will be loaded although the application will
maybe need only one.

Please take a look at how DBIx::Class::EncodedColumn,
DBIx::Class::UUIDColumns and DBIx::Class::InflateColumn::Serializer do
it. If you need help, I'd be glad to provide it to you.

Just my 2 cents,

Jose Luis Martinez
[hidden email]

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Bernhard Graf-4]

Jose Luis Martinez schrieb:

> 2- I see that the Markup::Unified module requires, uses, and makes an
> instance of the three markup modules that are supported. IMHO, I don't
> think this is a good long-term strategy if you are willing to support
> more modules because:
>  - If you only want to use one markup_lang, you have to install all, or
> the module fails to load.
>  - People have to "bug" you, as the maintainer of the module to get
> their markup language supported by Markup::Unified.
>  - All markup modules will be loaded although the application will maybe
> need only one.

That's a good point!
So Markup::Unified should be a universal markup class, that provides
methods to build and to traverse a markup object.

Then it would need Markup::Unified::Parser::* and
Markup::Unified::Formatter::* classes for all kind of input and output
formats. Those modules could be distributed seperatly.

Sounds like a big challenge. :-)
But I would estimate a certain amount of interest from wiki-application-
implementors for such a beast - if there is not already one out.

I think this is is getting a bit OT...


_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Alexander Hartmaier]

Am Mittwoch, den 30.09.2009, 12:45 +0200 schrieb Bernhard Graf:

> Jose Luis Martinez schrieb:
>
> > 2- I see that the Markup::Unified module requires, uses, and makes an
> > instance of the three markup modules that are supported. IMHO, I don't
> > think this is a good long-term strategy if you are willing to support
> > more modules because:
> >  - If you only want to use one markup_lang, you have to install all, or
> > the module fails to load.
> >  - People have to "bug" you, as the maintainer of the module to get
> > their markup language supported by Markup::Unified.
> >  - All markup modules will be loaded although the application will maybe
> > need only one.
>
> That's a good point!
> So Markup::Unified should be a universal markup class, that provides
> methods to build and to traverse a markup object.
>
> Then it would need Markup::Unified::Parser::* and
> Markup::Unified::Formatter::* classes for all kind of input and output
> formats. Those modules could be distributed seperatly.
>
> Sounds like a big challenge. :-)
> But I would estimate a certain amount of interest from wiki-application-
> implementors for such a beast - if there is not already one out.
>
> I think this is is getting a bit OT...

Sound to me like you need to write a module which represents the markup
column data as object and inflate to it with DBIC.

--
BR Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH   Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...