I have Custom Content Type in Orchard, with coresponding part of same name with two text fields, defined in migrations. The part definition is as follows:
ContentDefinitionManager.AlterPartDefinition("Faq",
cfg => cfg
.Attachable()
.WithField("Question", f => f
.OfType("TextField")
.WithDisplayName("Question")
.WithSetting("Flavor","Wide"))
.WithField("Answer", f => f
.OfType("TextField")
.WithDisplayName("Answer")
.WithSetting("Flavor", "Html"))
This adds the fields to the part, but the setting is not applied - both fields have the default flavor in the dashboard. I believe it is just a silly typo but I'm unable to figure it out.
Yeah, adding fields in migrations can be a little fiddly. What you really need is instead of just "Flavor", you need its fully qualified name, "TextFieldSettings.Flavor".
I've actually started adding a feature to Orchardizer (a VS extension) that will transform your export code into migrations code, so it'll build all that stuff for you. Should be done by the weekend (if I don't start feeling lazy)
Related
So I have a simple parser library (it doesn't parse strings but whatever) and I need the parsers to have potential names etc.
So, for example, the user might take the parsers
space >> space
and then apply the name twoSpaces to this parser. This would then be saved to disk (not sure how exactly) to be later reloaded when the application is rerun.
So my question is:
Should this functionality be wrapped say in this:
type Name = String
newtype NamedParser a = NamedParser (Parser a) Name
Or should my definition of Parser be changed from:
newtype Parser a = Parser { parse :: a -> FilterResult a }
to:
newtype Parser a = Parser { parse :: a -> FilterResult a
, name :: Name }
My intuition worries here about both speed of the program and implementation (sometimes I won't want to name parsers etc).
An extension of this question is whether I can then allow the user to save these new parsers in data files for between runtimes. This way the user can build a library of tools that can load in.
I can imagine a good way of doing this being an appropriate Writer/Parser duo that saves this stuff to files, with the resulting Haskell code then added to my libraries. Is there a convention for such things or is that what I should go for. Is TemplateHaskell a better alternative for this??
Finally, how would I add and delete these new metaprogrammed functions​ efficiently - is there a convention for that?
I am writing a Shakefile with the aim of making it extensible with new Rules. Its interface is a function mainFor :: Rules () -> IO (), the idea being that client projects would only need to define main = mainFor myCustomRules to get the whole thing working. mainFor customRules is defined as a bunch of Shake Rules followed by a call to customRules.
This works as long as the custom rules passed to mainFor are for new targets.
However, some of my stock (non-custom) rules are basically of the form "run this big opaque proprietary external script with this input and hope for the best"; and there can be extra files used by the external script depending on its input. For example, imagine I have a rule of the following form:
"_build/output.bin" %> out -> do
need ["_build/script.scr", "_build/src/generated.src"]
runExternalScript
For a particular client project, maybe the generated source code contains references to another file _build/src/extrainput.src. So in the custom rules passed to mainFor, not only do I need extra rules for this file, but the existing rule should also be modified to mark that it needs this input:
main = mainFor $ do
"_build/src/extrainput.src" %> \out -> do
generateExtraSrc
"_buld/output.bin" %> \out -> do
need ["_build/src/extrainput.src"]
but this, unsurprisingly, fails because both the stock rule in mainFor and the second custom rule passed in the customRules argument are for the same target. Note that I do not want to fully override the stock rule, only extend it to add the extra dependency.
There is currently no way to do this using Shake. The possibilities are:
Add it to Shake. Whether that's the right thing depends on how common this requirement is - and my guess is relatively rare - but that needs validating. The fact you want the dependencies run before the rule is more concerning - it's somehow less compositional than just providing multiple actions that together produce a result.
Do it on the outside. My straw man would be to write the "extras" as some kind of FilePath -> Action () function, then define your own %> that also applied that function to the output. It would only work with pre-selected extension points, but if you redefine %> at the top of the file it can hit all your instances.
If you really want to hide it more, use shakeExtra to store the state in some way.
today on "adventures in functional programming with lenses" our hero attempts to define a prism over a list element that may or may not exist.
It's a bit tricky to explain, so to avoid the X, Y problem I'll give the actual use-case in all its glory.
I'm writing a Text editor in Haskell called Rasa, the whole idea is that it's extremely extensible, and that means most functionality is written as extensions. Since it's a core principle, extensions ALSO depend on other extensions, so I needed a way to store their state centrally such that all extensions depending on an extension could access its current 'extension state'. Of course the types of these states is not known to the core of the editor, so at the moment I'm storing a list of Dynamic values. When the extension stores the state it converts to a Dynamic, then it can be extracted later via a prism like so:
data Store = Store
{ _event :: [Event]
, _editor :: E.Editor
, _extState :: [Dynamic]
}
ext :: Typeable a => Traversal' Store a
ext = extState.traverse._Dynamic
So now ext is a polymorphic Traversal that essentially operates over only the Dynamics that 'match' the type in question (if you set to it it'll replace values of the same type, if you 'get' from it, it acts as a traversal over the Dynamics that match the type of the outbound value). If that seems like magic, it basically is...
BTW, I'd love to have exactly 1 copy of a given Extension's state object in the list at any time.
So getting and setting is actually working fine IFF there's already a value of the proper type in the list, my question is how can I make a version of this Traversal such that if a value of the proper type is in the list that it will replace it (and getting works as expected), but that will ADD a value to the list if the traversal is SET to and there's NO matching element in the list. I understand that Traversal's aren't supposed to change the number of elements that they're traversing, so perhaps this needs to be a prism or lens over the list itself?
I understand this is really confusing, so please ask clarifying questions :)
As for things I've taken a look at already, I was looking at prefixed and _Cons as possible ways to do this, but I'm just not quite sure how to wire it up. Maybe I'm barking up the wrong tree entirely.
I could perhaps add a default value to the end of the traversal somehow, but I don't want to require Monoid or Default so I can't conjure up elements from nowhere (and I only want to do it when SETTING).
I'm also open to discussions about whether this is actually the proper way to store this state at all, but it's the most elegant of solutions I've found so far (though I know typecasting at run time is sub-optimal). I've looked into the Vault type, but passing keys around didn't really work well when I tried it (and I imagine it has similar type-casting performance issues).
Cheers! Thanks for reading.
I think the list of extensions is not proper solution for you. I would be added something like _extState :: Map TypeRep Ext where data Ext = forall a. Ext a. Then I would be added the lens:
ext :: forall a . Typeable a => Lens' Store (Maybe a)
ext = _extState . at (typeRep (Proxy :: Proxy a)) . mapping coerce
where
coerce = iso (\(Ext x) -> unsafeCoerce x) Ext
This lens does like at. So you can simply get/set your extensions.
But there is one limitation, all extensions must be of different types.
I'm using PHPStorm EAP version PS-138.940.
I have code as follows:
Config(__NAMESPACE__."\ObjectsToIdentifiers")->oldTables = array('Modules\Old\Model\DeviceStock','Modules\Old\Model\ProductPack','Modules\Old\Model\SpareStock','Modules\Old\Model\ConsumStock');
The functionality is irrelevant in this case. Important are the entries in the array. These are fully qualified class names - the leading / is omitted, but adding it doesn't solve my problem. I want to be able to click inside one of the string literals, press Ctrl+B and be redirected to the class definition.
Note that this works in ExtJS (javascript framework) where a string literal like
"MyApp.namespace.view.MyComponent"
will take me there.
Is there any way to manually configure this or do I have to submit a feature request. If so, how can I do that?
Update 1:
I created a feature request on JetBrains Youtrack: http://youtrack.jetbrains.com/issue/WI-24262
Came across this question looking for something in Storm that would let me quickly convert "\Some\ClassName" to Some\ClassName::class like an Intention or plugin, but so far have found nothing.
i'm surprised the ::class static property hasn't been mentioned. It produces the FQN of the Class, and resolves from import aliases.
The following should be a legit rewrite that the IDE can resolve:
// Same __NAMESPACE__, so no prefix needed
Config(ObjectsToIdentifiers::class)
->oldTables = [
Modules\Old\Model\DeviceStock::class,
Modules\Old\Model\ProductPack::class,
Modules\Old\Model\SpareStock::class,
Modules\Old\Model\ConsumStock::class
];
// or, if you import the classes:
use Modules\Old\Model\DeviceStock as OldDeviceStock;
// you can refer to
OldDeviceStock::class;
Unfortunately, right now if you jump-to-definition of the alias, Storm won't take you to the actual class, but where the alias is defined. Not terribly helpful, but gets you halfway since the actual class is right there.
I need to create a function f:: Log->[String] that does that (((o, i ,d),s) = [(o, i ,d)]
type Log = (Plate, [String])
type Plate = (Pin, Pin, Pin)
type Pin = (Char, Int)
If you're on a page like this, click "Source" on the fir right side, next to the function that you're interested in.
If you need to look up a function, Hayoo! and Hoogle will link you to documentation pages like the one above.
An important thing to note, though is that show doesn't have one definition. show is a function defined for all data types in the Show (with a capital "S") typeclass. So for example, here is the full source for the Show typeclass. Show is defined within the typeclass as just show :: a -> String. But if you search for "instance Show Bool" or "instance Show Int", you'll find specific definitions.
For the second part of your question, the easiest way to get a show function for a new type is to simply write deriving (Show) below it. For example,
data Foo = Foo Int Int
deriving (Show)
Now I can use show on data with type Foo.
g :: Log -> [String]
g (plate, _) = [show plate]
Use hoogle to find this sort of information.
Example: http://www.haskell.org/hoogle/?hoogle=show
Once you've found the function you'd like in the list, click and there you'll find a Source link on the right hand side of the page.
NB this is an answer to the original question:
Where can I see the codes of the predefined functions in haskell ?? Mainly the function SHOW?
It's true that you can use Hoogle to search for functions defined in the Prelude (and other modules), but the source code itself is located at Hackage.
Hackage is a database of Haskell packages. You can download new packages from it, and also view the Haddock documentation for every package in the database.
This is the Haddock page for the standard Prelude. It documents the type classes, data types, types, and top-level functions exported by the Prelude module. To the right of each definition header is a link that says "Source". You can click this to be taken to an online copy of the source code for the module you're viewing.
On preview, you're now asking a different question entirely, and on preview again in fact the original question has been edited out of this post.
Your new question is unclear, but this solution will work to produce the output in your example.
> [fst ((('O',0),('I',0),('D',1)),"O->D")]
[(('O',0),('I',0),('D',1))]
I think you're using list notation instead of double quotes to identify Strings, by the way, so I fixed that around 0->D above. So you might also try this instead.
> show (fst ((('O',0),('I',0),('D',1)),"O->D"))
"(('O',0),('I',0),('D',1))"
This works because you have only defined type synonyms (by using type in your declarations instead of data) on data structures which already have Show instances.