First login?
Lost password?
 
 
 
General mailing list for discussions and development of PeerLibrary and related software.

List archive Help


Re: [PeerLibrary dev] PeerDB vs. Meteor collection queries


Chronological Thread 
  • From: Mitar < >
  • To:
  • Subject: Re: [PeerLibrary dev] PeerDB vs. Meteor collection queries
  • Date: Thu, 14 Aug 2014 07:06:36 -0700
Hi!

> You would have to define dependencies like in [1] but you write so much
> code for stuff that should be really simple.

This is because that blog post does not use Variable package. This is a
simple wrapper around new Deps.Dependency.

> the new 'UI._templateInstance()' again is based on a global
> variable.

You mean the UI variable? Yes, so? :-)

> This might seem to be a good idea but it's not that easy because "URLs
> over 2000 chars will not work in most popular web browsers" [2].

That why we are storing a hash for the rest. In the worst case, we will
store just hash without query strings, but I do think that for example
for filtering input box we should store that into a query string. So
slugs and query strings are a goody to make things more readable. In the
worst case we can always have:

/p/<document_id>#<hash>

This is not too long. But sometimes we will have:

/p/<document_id>/<slug>#<hash>

Or:

/p?filter=foobar#<hash>

This is also not too long.

> Also, it's cumbersome to store some parts, e.g., which dialog boxes
> are open or which strings are entered in which forms.

Which dialog box is open is not a problem, if we store those flags into
Session. Of course, we might decide that some dialog boxes are
unnecessary to store (like confirmation dialog boxes, which we do not
really use and I would not really like to use - but provide undo
capability instead).

Which strings are entered into which form would not be stored into the
session. It is part of DOM. Or it is part of the document from MongoDB.
(With auto-saving for more complicated stuff.)

> And with userdata, you'll exceed the 2000 char limit easily. Isn't a link
> to a certain publication and an additional identifier (like the position
> in the doc) in the hash part enough?

You store only hash for state into the URL. You store state on the
server into a specialized collection.

> Don't get me wrong: having a session isn't bad at all for certain data,
> e.g., information about the user's login state. But in my opinion, UI
> components such as search fields should not store their data in global
> variables.

UI components as search fields should store their data into URL, and
global variable (not variables) should then reflect that URL.

>> If you want to dive into one more aspect of Meteor, their use of fiber,
>> pleas help me with this. I am stuck:
>>
>> https://stackoverflow.com/questions/25248493/how-to-use-fibers-with-streams
>
> No idea about that one. ;)

Not helpful! Why is nobody interested in event-driven loops,
concurrency, and coroutines in JavaScript? :-( It is so much fun!


Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

Archive powered by MHonArc 2.6.18.

Top of page