Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
Per Cederberg
DragAndDrop and Sortable. I found a previous discussion of that in
this thread:
http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99
None of the two modules have been much modified lately, so perhaps
they are now stable? Otherwise, I think we should make the docs
clearer regarding their status and how to use them.
Cheers,
/Per
PS. I just discovered that Google Groups silently dropped all my
emails that used another sender address, so I'm currently resending
all my recent postings. Hence the sudden email bombing...
Arnar Birgisson
On Wed, Oct 8, 2008 at 15:38, Per Cederberg <cede...@gmail.com> wrote:
> The packed version of MochiKit still doesn't include the modules
> DragAndDrop and Sortable. I found a previous discussion of that in
> this thread:
>
> http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99
>
> None of the two modules have been much modified lately, so perhaps
> they are now stable? Otherwise, I think we should make the docs
> clearer regarding their status and how to use them.
Including them is fine with me, but for my own purposes I don't use
that.. since for me MochiKit serves purely as a utility library rather
than one of UI elements. I suspect there are others in a similar
situation.
What we really should do, and it should not be too hard, is make
several packed versions. Basically for every module we'd provide a
"dependency-closed" packed version - i.e. one that includes that
module and all of its dependencies. Modifying the "packed" script to
perform this should be doable.
If people don't like the idea of so many packed versions, perhaps we
could decide on two or three "feature-sets" and provide packed
versions of these. I know MochiKit is not that big, and download time
is not really the issue - but bandwidth can be an issue for the host.
cheers,
Arnar
Per Cederberg
For version 1.5 I think we should consider having a nice little
download web page where you can customize your packed version of
MochiKit. I created a little dummy UI to show what I mean:
http://www.percederberg.net/mochikit/pack.html
If we plunge forward and start adding more extension modules (as
suggested here before), I think such a UI would be important to keep
all users happy.
Cheers,
/Per
Arnar Birgisson
> For version 1.5 I think we should consider having a nice little
> download web page where you can customize your packed version of
> MochiKit. I created a little dummy UI to show what I mean:
>
> http://www.percederberg.net/mochikit/pack.html
Yes, yes, excellent - +1 on that from me.
Minor usability pointer: When unselecting a module, instead of
unselecting everything that depends on it - highlight the relevant
part of "uses XXX" of those in some /error/ color.
cheers,
Arnar
Jason Bunting
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.173 / Virus Database: 270.8.0/1722 - Release Date: 10/13/2008
> 7:50 AM
Bob Ippolito
to it... mostly because it's hard to do client side and I didn't want
that feature to be dependent on some server-side script.
My thinking was that we'd keep packed versions of every module (so
that we could continue to use the Java based packer, instead of
implementing a JavaScript version)[1] and some client-side could could
XHR them all down and concatenate them in the correct order, but the
problem is allowing the user to actually download that text. Using the
pasteboard would work I guess, but that's not a nice solution.
I suppose we could set something up where the client just does a POST
to some URL (maybe an app engine service or something) and the server
simply echos it back with a Content-Disposition header that forces
download.
[1] But maybe it would be reasonable to write an entirely JS based
packer with Narcissus
http://mxr.mozilla.org/mozilla/source/js/narcissus/ -- are there any
other projects like this that I'm not aware of?
-bob
Per Cederberg
I also gave the download issue some thought. Seems it would be
possible to spoof a download in IE and Firefox (with privilege
escalation warning). But not on Safari. And anyway, it would be an
ugly and messy hack.
So my next thought would be to create something in Flash that could
save a file locally. We can even supply it with the actual text file
content from JS just like Bob explained. Is that doable? I don't have
a license for that stuff and have never worked in Flash myself, so
perhaps I'm just dead wrong here.
Third option would be to just open a window with the packed text and
ask the user to do Ctrl-S. Perhaps by setting the window title or
something.
Cheers,
/Per
Bob Ippolito
You can build Flash content with free tools though (Adobe Flex 2 SDK,
MTASC, haXe, etc.).
-bob
Per Cederberg
> Minor usability pointer: When unselecting a module, instead of
> unselecting everything that depends on it - highlight the relevant
> part of "uses XXX" of those in some /error/ color.
I fooled around a bit with the visual effects instead...
http://www.percederberg.net/mochikit/pack.html
Cheers,
/Per
Arnar Birgisson
> I fooled around a bit with the visual effects instead...
> http://www.percederberg.net/mochikit/pack.html
Ah, nice, very nice.
As for the other thing (generating the pack) - I don't think there is
a good, clean way to do it on the client side and probably something
server side (it can be dead-simple) is the way to go.
Although, there is one outrageous possibility: We could pregenerate
all possible combinations of modules. Now, before you call me crazy,
note that even if 14 modules could potentially mean 2^14~=16k
different combinations, the dependency graph puts severe restrictions
on that. So for fun, I decided to see how many there really are. Given
the dependency specs Per used in the above html file, there are
exactly 1952 possible combinations such that all dependencies are
included :D
Now, generating these 1952 files every time there is a commit might
seem stupid, but it is actually doable :)
Ok, now feel free to call me crazy.
Below this message is a Haskell program to find all legal combinations.
cheers,
Arnar
module Main where
import Control.Concurrent (forkIO)
import Control.Concurrent.MVar
import Data.Maybe (fromJust)
import Data.List (nub)
-- Modules in topological order, i.e.
-- a module must appear after all of its
-- dependencies
dependencies = [
("Base",[]),
("DateTime",["Base"]),
("Format",["Base"]),
("Iter",["Base"]),
("Async",["Base"]),
("DOM",["Base"]),
("Style",["Base"]),
("Color",["DOM", "Style"]),
("Logging",["Base"]),
("LoggingPane",["Logging"]),
("Selector",["DOM", "Style"]),
("Signal",["DOM", "Style"]),
("Visual",["Color"]),
("DragAndDrop",["Iter","Signal","Visual"]),
("Sortable",["DragAndDrop"])
]
modules = map fst dependencies
antichains :: MVar (Maybe [String]) -> IO ()
antichains channel = antichains' [] modules >> putMVar channel Nothing
where
antichains' :: [String] -> [String] -> IO ()
antichains' ac [] = putMVar channel (Just ac) >> return ()
antichains' ac (candidate:rest) =
do if ac `accepts` candidate
then antichains' (candidate:ac) rest
else return ()
antichains' ac rest
chain `accepts` candidate =
all (\c -> not . elem c
$ fromJust
$ lookup candidate dependencies) chain
closure :: [String] -> [String]
closure ms =
let missing = nub $ filter (not . flip elem ms)
$ concatMap (fromJust . flip lookup dependencies) ms
in
if null missing
then ms
else closure (ms ++ missing)
printer :: MVar () -> MVar (Maybe [String]) -> IO ()
printer stop in_ =
do v <- takeMVar in_
case v of
Just xs -> putStrLn $ show $ closure xs
Nothing -> putMVar stop ()
printer stop in_
main :: IO ()
main = do chan <- newEmptyMVar
stop <- newEmptyMVar
forkIO $ printer stop chan
forkIO $ antichains chan
takeMVar stop
return ()
Arnar Birgisson
On Mon, Oct 13, 2008 at 22:23, Arnar Birgisson <arn...@gmail.com> wrote:
> Although, there is one outrageous possibility: We could pregenerate
> all possible combinations of modules. Now, before you call me crazy,
> note that even if 14 modules could potentially mean 2^14~=16k
> different combinations, the dependency graph puts severe restrictions
> on that. So for fun, I decided to see how many there really are. Given
> the dependency specs Per used in the above html file, there are
> exactly 1952 possible combinations such that all dependencies are
> included :D
While I should probably point out that my last message was
tongue-in-cheek, there was also a glaring bug in my algorithm. After
fixing that and rerunning, the possible combinations are *merely* 817
:)
The correct code will appear on my blog in a few minutes.
http://www.hvergi.net/
cheers,
Arnar
Per Cederberg
the other day it just struck me that all we need to do, to enable
configurable packing, is to parse the packed version into modules. And
then allow the user to paste them back together.
So I developed a new demo that does that. Now it uses only a packed
version of MochiKit which it downloads as text and analyzes for
dependencies. Then creates the corresponding UI.
http://www.percederberg.net/mochikit/pack.html
As the standard packed version of MochiKit doesn't include DragAndDrop
and Sortable, I also included those in my source packed version.
The actual download button is still work-in-progress at this point.
Only works in Firefox and even then just sort-of-works. Will have to
ponder that a bit more before creating a final version.
Cheers,
/Per
Bob Ippolito
Content-Disposition set appropriately, you can put it in the google
app engine project that I built to fetch the blog and mailing list
feeds. Just let me know once the code is there and I'll update it.
http://svn.mochikit.com/mochikit.com/trunk/mochikit-dot-com/
-bob
Christoph Zwerschke
-- Christoph
Per Cederberg
It only provides customized downloads from svn trunk at the moment.
And due to the default packed version not including all modules, some
modules are not available...
If you have time, please try this out a bit. And report any issues
here, so that I'll have them fixed to the final version.
Cheers,
/Per