July 09, 2014 Re: critique of vibe.d | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to luminousone | Am 09.07.2014 21:21, schrieb luminousone:
> On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:
>> Am 09.07.2014 03:54, schrieb luminousone:
>>> There is lots of missing little bits here and their, password hashing
>>> functions that use crypt_(C) formated hashes.
>>
>> I was hoping for dauth [1] to fill that gap. It doesn't use the same
>> format, but one with the same goal. I didn't actually try it out yet,
>> though.
>>
>>>
>>> There are diet/jade template bugs still, specific major problem being
>>> that use of single quotes inside of double quotes when i need to pass
>>> strings to js functions inside of js events such as onclick inside a
>>> html tag, seems to be broken.
>>
>> Do you have a concrete example where this goes wrong? I've tested
>> both, nesting ' inside " and vice versa. Both seemed to work fine for
>> <body onLoad=...>.
>>
>>>
>>> There is not common database interface for sql databases(forgivable
>>> actually), but many of the specific database libraries are messy(ddb for
>>> example) and they are not any where near api "stable".
>>>
>>> Support for mongo is... cute?!, don't get me wrong it has a place, for
>>> most apps it would be fine, it is however unusable for the apps i am
>>> involved in.
>>
>> Yeah, I kind of like it for its flexibility, but it's definitely not
>> the right choice for million user web services. I'm currently looking
>> at NouDB as another potential SQL based target.
>>
>> [1]: http://code.dlang.org/packages/dauth
>
>
> hopefully, these posts are simply read as text, if not I can
> figure out something else.
>
> a.menu_item(href='#', onclick='load("invoice");') New Invoice
> a.menu_item(href='#', onclick="load('invoice');") New Invoice
>
> will always generate the following output,
>
> <a href="#" onclick="load("a");" class="menu_item">New
> Invoice</a>
> <a href="#" onclick="load('invoice');"
> class="menu_item">New Invoice</a>
That's right, but as far as I understand, it *should* work like that, because HTML character entity replacement should happen before parsing the JavaScript code, even if it's a little more verbose than it should be.
| |||
Permalink
ReplyJuly 09, 2014 Re: critique of vibe.d | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Dicebot | Am Wed, 09 Jul 2014 17:28:42 +0000
schrieb "Dicebot" <public@dicebot.lv>:
> On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau wrote:
> > Completely off-topic, but:
> >
> > Have you considered making vibe http-backend independent?
> > So that it could provide a fcgi interface or be included in an
> > nginx
> > plugin?
>
> What is the benefit as opposed to using proxy_pass at nginx? fcgi will be slower than built-in vibe.d HTTP server.
FCGI was only an example. I guess the only benefit is that the webserver can spawn fcgi backends when it starts and files with certain extensions can be handled with these backends.
But that's of course only useful with shared libraries / pages.
| |||
July 09, 2014 Re: critique of vibe.d | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | Am Wed, 09 Jul 2014 20:34:49 +0200 schrieb Sönke Ludwig <sludwig@rejectedsoftware.com>: > Am 09.07.2014 19:03, schrieb Johannes Pfau: > > Am Wed, 09 Jul 2014 18:16:49 +0200 > > schrieb Sönke Ludwig <sludwig@rejectedsoftware.com>: > > > >> Am 09.07.2014 17:26, schrieb Sean Kelly: > >>> On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote: > >>>> Also, in playframework, vert.x and nodejs, they all have a plugin/module system, that people could easily compose plugins to make a website. (I call it plugin because that is what play used to call it, now they all call it a module but that name will easily conflict with D's sourcecode modules). This is a critical mechanism that actually allured developers to contribute to the eco-system. > >>> > >>> On a related note, one thing vibe.d is really missing from my perspective is a good way to handle unstable processes and perform seamless code upgrades (this is where Erlang really shines IMO). It would be cool if there were a process monitor at least. The system I work with does some fancy stuff with UDS, but that probably isn't necessary. I'll admit that the ball is probably kind of in my court here, since IPC would be a handy way of communicating process health, but something simpler using pipes or whatever would work as well. > >> > >> This is what vibedist [1] was/is intended for, but unfortunately I never found the time to really finish it so far. > >> > >> [1]: https://github.com/rejectedsoftware/vibedist > > > > > > Completely off-topic, but: > > > > Have you considered making vibe http-backend independent? > > So that it could provide a fcgi interface or be included in an nginx > > plugin? > > That could be done pretty easily by providing an alternative to > listenHTTP() (e.g. void listenFCGI(HTTPServerRequestDelegate del)). > It could use the HTTPServerRequest and HTTPServerResponse classes > more or less just like the HTTP server does. > > > > > Also as D plugins now seem to work more or less have you considered loading webpages dynamically from .so files? > > > > Then we could invent some file extension - like .dpage - and have > > one vibe fcgi process handle all .dpage files. The process then > > simply loads the .dpage shared library, calls some function > > (extern(C) IWebSite vibe_get_site()) etc. > > > > Basically the way asp.net works, IIRC. > > > > That would be pretty much what Rikki Cattermole is planning to do with Cmsed [1]. For vibe.d it would be a bit too much at this time. There is still a lot that I would like to get done on the lower levels of the library, so that the basis is really solid sooner rather than later. The highest level features planned for now are the descriptive REST and web interface modules. > > However, there is a plan for using dynamic libraries to support seamless live editing/reloading of individual Diet templates [2]. > > [1]: http://code.dlang.org/packages/cmsed > [2]: https://github.com/rejectedsoftware/vibe.d/issues/676 I see, thanks. I think a CMS is usually a little higher-level then what I meant. But of course a name doesn't say much about what a project actually is ;-) | |||
July 09, 2014 Re: critique of vibe.d | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Sönke Ludwig | On Wednesday, 9 July 2014 at 19:51:38 UTC, Sönke Ludwig wrote:
> Am 09.07.2014 21:21, schrieb luminousone:
>> On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:
>>> Am 09.07.2014 03:54, schrieb luminousone:
>>>> There is lots of missing little bits here and their, password hashing
>>>> functions that use crypt_(C) formated hashes.
>>>
>>> I was hoping for dauth [1] to fill that gap. It doesn't use the same
>>> format, but one with the same goal. I didn't actually try it out yet,
>>> though.
>>>
>>>>
>>>> There are diet/jade template bugs still, specific major problem being
>>>> that use of single quotes inside of double quotes when i need to pass
>>>> strings to js functions inside of js events such as onclick inside a
>>>> html tag, seems to be broken.
>>>
>>> Do you have a concrete example where this goes wrong? I've tested
>>> both, nesting ' inside " and vice versa. Both seemed to work fine for
>>> <body onLoad=...>.
>>>
>>>>
>>>> There is not common database interface for sql databases(forgivable
>>>> actually), but many of the specific database libraries are messy(ddb for
>>>> example) and they are not any where near api "stable".
>>>>
>>>> Support for mongo is... cute?!, don't get me wrong it has a place, for
>>>> most apps it would be fine, it is however unusable for the apps i am
>>>> involved in.
>>>
>>> Yeah, I kind of like it for its flexibility, but it's definitely not
>>> the right choice for million user web services. I'm currently looking
>>> at NouDB as another potential SQL based target.
>>>
>>> [1]: http://code.dlang.org/packages/dauth
>>
>>
>> hopefully, these posts are simply read as text, if not I can
>> figure out something else.
>>
>> a.menu_item(href='#', onclick='load("invoice");') New Invoice
>> a.menu_item(href='#', onclick="load('invoice');") New Invoice
>>
>> will always generate the following output,
>>
>> <a href="#" onclick="load("a");" class="menu_item">New
>> Invoice</a>
>> <a href="#" onclick="load('invoice');"
>> class="menu_item">New Invoice</a>
>
> That's right, but as far as I understand, it *should* work like that, because HTML character entity replacement should happen before parsing the JavaScript code, even if it's a little more verbose than it should be.
It breaks the js. And the character entity replacement only
effects text between tags, with the exception of the script tag
which also does not get characters replaced, the existing
"script." tag in diet templates works correctly. Text inside of
attributes is not ran through the character entity replacement.
| |||
July 10, 2014 Re: critique of vibe.d | ||||
|---|---|---|---|---|
| ||||
Posted in reply to luminousone | Am 10.07.2014 01:27, schrieb luminousone: > On Wednesday, 9 July 2014 at 19:51:38 UTC, Sönke Ludwig wrote: >> Am 09.07.2014 21:21, schrieb luminousone: >>> On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote: >>>> Am 09.07.2014 03:54, schrieb luminousone: >>>>> There is lots of missing little bits here and their, password hashing >>>>> functions that use crypt_(C) formated hashes. >>>> >>>> I was hoping for dauth [1] to fill that gap. It doesn't use the same >>>> format, but one with the same goal. I didn't actually try it out yet, >>>> though. >>>> >>>>> >>>>> There are diet/jade template bugs still, specific major problem being >>>>> that use of single quotes inside of double quotes when i need to pass >>>>> strings to js functions inside of js events such as onclick inside a >>>>> html tag, seems to be broken. >>>> >>>> Do you have a concrete example where this goes wrong? I've tested >>>> both, nesting ' inside " and vice versa. Both seemed to work fine for >>>> <body onLoad=...>. >>>> >>>>> >>>>> There is not common database interface for sql databases(forgivable >>>>> actually), but many of the specific database libraries are >>>>> messy(ddb for >>>>> example) and they are not any where near api "stable". >>>>> >>>>> Support for mongo is... cute?!, don't get me wrong it has a place, for >>>>> most apps it would be fine, it is however unusable for the apps i am >>>>> involved in. >>>> >>>> Yeah, I kind of like it for its flexibility, but it's definitely not >>>> the right choice for million user web services. I'm currently looking >>>> at NouDB as another potential SQL based target. >>>> >>>> [1]: http://code.dlang.org/packages/dauth >>> >>> >>> hopefully, these posts are simply read as text, if not I can >>> figure out something else. >>> >>> a.menu_item(href='#', onclick='load("invoice");') New Invoice >>> a.menu_item(href='#', onclick="load('invoice');") New Invoice >>> >>> will always generate the following output, >>> >>> <a href="#" onclick="load("a");" class="menu_item">New >>> Invoice</a> >>> <a href="#" onclick="load('invoice');" >>> class="menu_item">New Invoice</a> >> >> That's right, but as far as I understand, it *should* work like that, >> because HTML character entity replacement should happen before parsing >> the JavaScript code, even if it's a little more verbose than it should >> be. > > It breaks the js. And the character entity replacement only > effects text between tags, with the exception of the script tag > which also does not get characters replaced, the existing > "script." tag in diet templates works correctly. Text inside of > attributes is not ran through the character entity replacement. This is not true. See http://www.w3.org/html/wg/drafts/html/master/syntax.html#attributes-0 On which browser does it break the JS for you? It works for me, at least in Opera and Firefox. | |||
July 10, 2014 Re: critique of vibe.d | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | On Thursday, 10 July 2014 at 00:02:23 UTC, Sönke Ludwig wrote:
> Am 10.07.2014 01:27, schrieb luminousone:
>> On Wednesday, 9 July 2014 at 19:51:38 UTC, Sönke Ludwig wrote:
>>> Am 09.07.2014 21:21, schrieb luminousone:
>>>> On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:
>>>>> Am 09.07.2014 03:54, schrieb luminousone:
>>>>>> There is lots of missing little bits here and their, password hashing
>>>>>> functions that use crypt_(C) formated hashes.
>>>>>
>>>>> I was hoping for dauth [1] to fill that gap. It doesn't use the same
>>>>> format, but one with the same goal. I didn't actually try it out yet,
>>>>> though.
>>>>>
>>>>>>
>>>>>> There are diet/jade template bugs still, specific major problem being
>>>>>> that use of single quotes inside of double quotes when i need to pass
>>>>>> strings to js functions inside of js events such as onclick inside a
>>>>>> html tag, seems to be broken.
>>>>>
>>>>> Do you have a concrete example where this goes wrong? I've tested
>>>>> both, nesting ' inside " and vice versa. Both seemed to work fine for
>>>>> <body onLoad=...>.
>>>>>
>>>>>>
>>>>>> There is not common database interface for sql databases(forgivable
>>>>>> actually), but many of the specific database libraries are
>>>>>> messy(ddb for
>>>>>> example) and they are not any where near api "stable".
>>>>>>
>>>>>> Support for mongo is... cute?!, don't get me wrong it has a place, for
>>>>>> most apps it would be fine, it is however unusable for the apps i am
>>>>>> involved in.
>>>>>
>>>>> Yeah, I kind of like it for its flexibility, but it's definitely not
>>>>> the right choice for million user web services. I'm currently looking
>>>>> at NouDB as another potential SQL based target.
>>>>>
>>>>> [1]: http://code.dlang.org/packages/dauth
>>>>
>>>>
>>>> hopefully, these posts are simply read as text, if not I can
>>>> figure out something else.
>>>>
>>>> a.menu_item(href='#', onclick='load("invoice");') New Invoice
>>>> a.menu_item(href='#', onclick="load('invoice');") New Invoice
>>>>
>>>> will always generate the following output,
>>>>
>>>> <a href="#" onclick="load("a");" class="menu_item">New
>>>> Invoice</a>
>>>> <a href="#" onclick="load('invoice');"
>>>> class="menu_item">New Invoice</a>
>>>
>>> That's right, but as far as I understand, it *should* work like that,
>>> because HTML character entity replacement should happen before parsing
>>> the JavaScript code, even if it's a little more verbose than it should
>>> be.
>>
>> It breaks the js. And the character entity replacement only
>> effects text between tags, with the exception of the script tag
>> which also does not get characters replaced, the existing
>> "script." tag in diet templates works correctly. Text inside of
>> attributes is not ran through the character entity replacement.
>
> This is not true. See http://www.w3.org/html/wg/drafts/html/master/syntax.html#attributes-0
> On which browser does it break the JS for you? It works for me, at least in Opera and Firefox.
Chrome, When the links are clicked they simply don't do anything,
the load function is not called. And it doesn't seem to throw any
errors in chromes developer tools, which does seem odd.
Your link is for the html 5.1 draft spec, might this be different
dependent on the version of html being used?
| |||
July 10, 2014 Re: critique of vibe.d | ||||
|---|---|---|---|---|
| ||||
Posted in reply to luminousone | Am 10.07.2014 02:30, schrieb luminousone: > he links are clicked they simply don't do anything, > the load function is not called. And it doesn't seem to throw any > errors in chromes devel I'll test with Chrome. But the spec is the same in that regard for HTML 4: http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2 It even explicitly mentions escaping of " and ' | |||
July 10, 2014 Re: critique of vibe.d | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | Am 10.07.2014 02:58, schrieb Sönke Ludwig:
> Am 10.07.2014 02:30, schrieb luminousone:
>> he links are clicked they simply don't do anything,
>> the load function is not called. And it doesn't seem to throw any
>> errors in chromes devel
>
> I'll test with Chrome. But the spec is the same in that regard for HTML 4:
> http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
>
> It even explicitly mentions escaping of " and '
All of these work for the latest Chrome (as well as for Opera, Firefox and IE11):
<html><body>
<a href="#" onClick="alert('Hello, World!')">Using &#39;</a><br>
<a href="#" onClick="alert("Hello, World!")">Using &quot;</a><br>
<a href="#" onClick="alert('Hello, World!')">Using '</a><br>
<a href="#" onClick='alert("Hello, World!")'>Using "</a><br>
</body></html>
| |||
July 10, 2014 Re: critique of vibe.d | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Johannes Pfau | On 10/07/2014 9:12 a.m., Johannes Pfau wrote:
> Am Wed, 09 Jul 2014 20:34:49 +0200
> schrieb Sönke Ludwig <sludwig@rejectedsoftware.com>:
>
>> Am 09.07.2014 19:03, schrieb Johannes Pfau:
>>> Am Wed, 09 Jul 2014 18:16:49 +0200
>>> schrieb Sönke Ludwig <sludwig@rejectedsoftware.com>:
>>>
>>>> Am 09.07.2014 17:26, schrieb Sean Kelly:
>>>>> On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote:
>>>>>> Also, in playframework, vert.x and nodejs, they all have a
>>>>>> plugin/module system, that people could easily compose plugins to
>>>>>> make a website. (I call it plugin because that is what play used
>>>>>> to call it, now they all call it a module but that name will
>>>>>> easily conflict with D's sourcecode modules). This is a critical
>>>>>> mechanism that actually allured developers to contribute to the
>>>>>> eco-system.
>>>>>
>>>>> On a related note, one thing vibe.d is really missing from my
>>>>> perspective is a good way to handle unstable processes and perform
>>>>> seamless code upgrades (this is where Erlang really shines IMO).
>>>>> It would be cool if there were a process monitor at least. The
>>>>> system I work with does some fancy stuff with UDS, but that
>>>>> probably isn't necessary. I'll admit that the ball is probably
>>>>> kind of in my court here, since IPC would be a handy way of
>>>>> communicating process health, but something simpler using pipes
>>>>> or whatever would work as well.
>>>>
>>>> This is what vibedist [1] was/is intended for, but unfortunately I
>>>> never found the time to really finish it so far.
>>>>
>>>> [1]: https://github.com/rejectedsoftware/vibedist
>>>
>>>
>>> Completely off-topic, but:
>>>
>>> Have you considered making vibe http-backend independent?
>>> So that it could provide a fcgi interface or be included in an nginx
>>> plugin?
>>
>> That could be done pretty easily by providing an alternative to
>> listenHTTP() (e.g. void listenFCGI(HTTPServerRequestDelegate del)).
>> It could use the HTTPServerRequest and HTTPServerResponse classes
>> more or less just like the HTTP server does.
>>
>>>
>>> Also as D plugins now seem to work more or less have you considered
>>> loading webpages dynamically from .so files?
>>>
>>> Then we could invent some file extension - like .dpage - and have
>>> one vibe fcgi process handle all .dpage files. The process then
>>> simply loads the .dpage shared library, calls some function
>>> (extern(C) IWebSite vibe_get_site()) etc.
>>>
>>> Basically the way asp.net works, IIRC.
>>>
>>
>> That would be pretty much what Rikki Cattermole is planning to do
>> with Cmsed [1]. For vibe.d it would be a bit too much at this time.
>> There is still a lot that I would like to get done on the lower
>> levels of the library, so that the basis is really solid sooner
>> rather than later. The highest level features planned for now are the
>> descriptive REST and web interface modules.
>>
>> However, there is a plan for using dynamic libraries to support
>> seamless live editing/reloading of individual Diet templates [2].
>>
>> [1]: http://code.dlang.org/packages/cmsed
>> [2]: https://github.com/rejectedsoftware/vibe.d/issues/676
>
> I see, thanks. I think a CMS is usually a little higher-level then what
> I meant. But of course a name doesn't say much about what a project
> actually is ;-)
Unfortunately right now Cmsed doesn't for-fill its purpose in the CMS area. But basically I use dub sub packages so if you didn't want to go full in, you didn't need to.
I.E. the base web service framework is literally called cmsed:base and it would give you most of the nice ness e.g. router, javascript generation and Dvorm integration (ORM and works rather well in my opinion).
Where as cmsed:user would provide just user authentication and storage mechanism.
| |||
July 10, 2014 Re: critique of vibe.d | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Nick Sabalausky | On 09/07/14 20:34, Nick Sabalausky wrote: > Can't it be used as a complete web framework? I mean, assuming you're > happy with the built-in templating and DB options? Or is everyone using > "web framework" here to really mean "CMS"? I don't know. But to me they're not the same. You can use a web framework to build a CMS. -- /Jacob Carlborg | |||
Copyright © 1999-2021 by the D Language Foundation