Re: Some comments/suggestions from a new user

On Wed, Nov 30, 2011 at 7:33 AM, Tim <tim.ringenbach@...> wrote:
> Hi all,
>
> I was a little bit confused by references to Hamlet and Persistent
> being their own projects. I googled to see if their had their own
> sites or separate documentation, but that just let me back to the
> yesod website.

They have their own packages and are decoupled. They can and are used
separately from Yesod.

> The Persistent section of the Yesod book leaves me with some
> questions.  Some other frameworks talk about convention over
> configuration. They typically have these Model classes which
> assumptions like the table name is the class name in lowercase, and
> all of the fields are columns, but usually let you override these
> defaults by setting special properties. Often there's a tool to
> reverse engineer an existing schema and generate model classes for an
> existing database, as well as doing the opposite (generating the
> database from model classes, which is usually encourage over the other
> direction).
>
> Persistent seems like it might be Convention Only, with no way to
> override table or column names. I'm not sure if that's true or not, or
> if that's a design decision or just a "someday" feature, I don't think
> the book told me.

Person sql=the-person-table
    firstName String sql=first_name
    lastName String sql=fldLastName

Re: Some comments/suggestions from a new user

On Nov 30, 6:04 pm, Aur Saraf <sonofli...@...> wrote:
> On Wed, Nov 30, 2011 at 7:33 AM, Tim <tim.ringenb...@...> wrote:
> > The Persistent section of the Yesod book leaves me with some
> > questions.  Some other frameworks talk about convention over
> > configuration. They typically have these Model classes which
> > assumptions like the table name is the class name in lowercase, and
> > all of the fields are columns, but usually let you override these
> > defaults by setting special properties. Often there's a tool to
> > reverse engineer an existing schema and generate model classes for an
> > existing database, as well as doing the opposite (generating the
> > database from model classes, which is usually encourage over the other
> > direction).
>
> > Persistent seems like it might be Convention Only, with no way to
> > override table or column names. I'm not sure if that's true or not, or
> > if that's a design decision or just a "someday" feature, I don't think
> > the book told me.
>
> Person sql=the-person-table
>     firstName String sql=first_name
>     lastName String sql=fldLastName
>     age Int Gt Desc "sql=The Age of the Person"
>     UniqueName firstName lastName
>
> http://www.yesodweb.com/book/persistent#file341-attributes-x9

Thanks. Actually, I think I read that, and the raw SQL example after
it, and somehow I forgot about them. Sorry about that.

Multiselect field 'id'

I was just trying to use the multiSelectField element and found out
that the value in the option tag is just a number that is supposed to
reflect the position in the entering table. However, this doesn't seem
to me a good idea - if you are reading the data from the database, it
may happen, that the other time you read it in different order or that
somebody changes the items in the database before the submission.

Additionally, the signature of the function (Eq a, Show a) suggests,
that it could rather use (show a) as the option value attribute. Is
there any reason not to use such a scheme?

Ondrej

Re: Default authentication options

http://www.startssl.com/?app=1

Free ssl certs that are recognized by modern browsers. I use them for
web and email.

On Sat, 2011-11-19 at 18:04 -0800, Michael Snoyman wrote:
> Even if we provide SSL out-of-the-box (which we already do in master),
> there are still two reasons why a user won't be able to use it:
> 
> * They would need to buy an SSL cert, or face the wrath of self-signed
> certs. (Don't get me started on that rant against the browsers...)
> * It won't work if you have virtual hosts.
> 
> So to be clear: I don't think we can *ever* ship with something
> out-of-the-box which requires SSL to be present.
> 
> I'm not sure I agree with the assertion that we can't use cookies
> without SSL. With IP address pegging, it is very difficult for MIIM
> attacks to work against clientsession.
> 
> Michael
> 
> On Nov 19, 2011 6:28 AM, "Greg Weber" <greg@...> wrote:
>         I like Michael's suggestions for the situation we have at the
>         moment, but we need to make it as easy as possible for
>         everyone with login to use SSL and then we should bring email
>         back.
>         
>         
>         One issue with email is the sendmail requirement. This can be

Some upcoming Lucius changes (now on Github)

Hi all,

I wanted to announce some upcoming changes for Lucius.

1. A number of people have requested variable support. I was hesitant
at first, as this overlaps with Haskell variables, but it really is
too useful a feature not to have. Syntax is stolen from Less:

         <at> myColor: red;
        p { color: #{myColor}; }
        div { color: #{myColor}; }

    Note that you can only declare raw strings as the values of a
variable, not refer to other variables. We can consider relaxing this
in the future.

2. Runtime Lucius, as a parallel to runtime Hamlet. It does not
support any URL interpolation (I can't think of a use case where that
would be relevant), only interpolating raw text values.

3. Until a better name comes along: servius, a standalone server
(based on Warp and wai-app-static) that will render Hamlet and Lucius
on-the-fly.

This trifecta comes in *very* handy for mocking up some HTML/CSS
before integrating it into an actual site.

Michael

Re: Re: Some comments/suggestions from a new user

On Thu, Dec 1, 2011 at 5:43 AM, Tim <tim.ringenbach@...> wrote:
>
>
> On Nov 30, 6:04 pm, Aur Saraf <sonofli...@...> wrote:
>> On Wed, Nov 30, 2011 at 7:33 AM, Tim <tim.ringenb...@...> wrote:
>> > The Persistent section of the Yesod book leaves me with some
>> > questions.  Some other frameworks talk about convention over
>> > configuration. They typically have these Model classes which
>> > assumptions like the table name is the class name in lowercase, and
>> > all of the fields are columns, but usually let you override these
>> > defaults by setting special properties. Often there's a tool to
>> > reverse engineer an existing schema and generate model classes for an
>> > existing database, as well as doing the opposite (generating the
>> > database from model classes, which is usually encourage over the other
>> > direction).
>>
>> > Persistent seems like it might be Convention Only, with no way to
>> > override table or column names. I'm not sure if that's true or not, or
>> > if that's a design decision or just a "someday" feature, I don't think
>> > the book told me.
>>
>> Person sql=the-person-table
>>     firstName String sql=first_name
>>     lastName String sql=fldLastName
>>     age Int Gt Desc "sql=The Age of the Person"
>>     UniqueName firstName lastName
>>
>> http://www.yesodweb.com/book/persistent#file341-attributes-x9
>
> Thanks. Actually, I think I read that, and the raw SQL example after

Re: Multiselect field 'id'

It looks like selectField has an alternative that uses customizable
options, but no one has written a version of that for multiSelectField
yet.  It probably wouldn't take a ton of work.  Just gotta modify the
multiSelectHelper function and make both multiSelectField functions
use it properly.

On Thu, Dec 1, 2011 at 8:37 PM, ondra <palkovsky.ondrej@...> wrote:
> I was just trying to use the multiSelectField element and found out
> that the value in the option tag is just a number that is supposed to
> reflect the position in the entering table. However, this doesn't seem
> to me a good idea - if you are reading the data from the database, it
> may happen, that the other time you read it in different order or that
> somebody changes the items in the database before the submission.
>
> Additionally, the signature of the function (Eq a, Show a) suggests,
> that it could rather use (show a) as the option value attribute. Is
> there any reason not to use such a scheme?
>
> Ondrej

Yesod.Config questions

Re: Yesod.Config questions

On Mon 05 Dec 2011 10:42:46 AM CET, Kirill Zaborsky wrote:
> Hello,
> I'm somewhat stuck trying to find some easy solution with the 
> following constraints:
>  1. (main objective) We need to put application settings not to 
> ./config/settings.yml but in /etc/≤service-name>/settings.yml The only 
> solution at the moment I see for this is to copy-paste code from 
> Yesod.Config and add some code changing "config/settings.yml" to the 
> needed value (e.g. if there is no "config" directory in the working 
> directory)
>  2. We need additional settings but AppConfig contains just 3 fields 
> and that's all. Having 2 files instead of 1 doesn't seem to be a good. 
> And also we need to duplicate logic for checking "config" subfolder as 
> function with<AppName> is called after main config is loaded.
>  3. It makes no sense to have development settings on production server.
>  4. For development I'd like to use "yesod devel" and implementation 
> in yesod-default won't allow (3) ot be realized.
>
> What do you think?
> Maybe I'm missing something and configuration could be organized some 
> other way around with no such problems like the ones I describe above.
> Any advice welcomed.
>
> Kind regards,
> Kirill Zaborsky

I'm very interested in solutions to these problems aswell. I think this 
issue is related: https://github.com/yesodweb/yesod/issues/168

Cheers,
Arash

Re: Yesod.Config questions